Transaction and communication system and method for vendors and promoters

ABSTRACT

Transaction and communication systems and methods are disclosed for vendors and promoters. Some embodiments disclosed herein provide a deal manager system comprising transaction data associated with the promotional activities of one or more promoters, such as promoters registered with the deal manager system. The deal manager system can process the transaction data and provide compensation to promoters for their promotional activities based at least partly thereon. In certain embodiments, at least a portion of the transaction data can be provided to one or more vendors. A vendor may direct that benefits or promotional material be provided to a subset of promoters based at least in part on the received transaction data. The deal manager system may include promoter contact information, and materials provided by the vendor may be conveyed by the deal manager system to certain promoters based on the same.

BACKGROUND

The present disclosure relates to the field of for-hire vehicles such astaxis, limousines, shuttles, buses or any other vehicle that providesshared transportation or transports one or more passengers betweenlocations of the passengers' choice. The present disclosure also relatesto the field of advertising, sales and promotion.

A for-hire vehicle (FHV) generally charges fares for transporting apassenger from one location to another. Some FHVs, such as taxicabs,operate with a meter, while others such as limos and shuttles transportpassengers for a pre-trip negotiated rate. FHVs are common in touristdestinations, business traveler destinations (for example, whereconvention centers are prevalent) or in densely populated urban areaswhere vehicle ownership is relatively less common or impractical. Areasof high FHV use often offer numerous entertainment options. Theentertainment options may include, among other things, shows, plays,concerts, dining, sporting events, or other special events. Travelers,business people and urban dwellers may frequent these entertainmentoptions through the use of a FHV. For example, a business person in townfor a convention may wish to dine at a restaurant and may hail a taxi totransport him to the restaurant. Individual service providers, such astaxi drivers, may be consulted for their recommendations regardingentertainment or dining options. Therefore, dining and entertainmentvenues may desire access to, or contact with, taxi drivers or otherservice providers in order to increase the likelihood that their goodsor services will be recommended.

Many entertainment options are time, location and quantity sensitive;the entertainment options offer a service that is available for a fixedtime, at a specific location and only for a fixed number of people. Forexample, a play may start at 8 PM (fixed time), be performed at theDowntown Theater (specific location) and have 200 seats available (fixednumber of people). In some cases, the number of tickets sold for theevent is less than the seats available. For example, only 150 ticketsmay have been sold for the play in the 200 seat venue. As the 8 PM starttime approaches, it may become clear to the vendor operating the play atthe venue that the remaining 50 seats will not be sold. Once the playstarts, any empty seat in the venue is a lost revenue opportunity.Restaurant owners face a similar lost revenue opportunity, even thoughthe restaurant option may not have strictly fixed time. Empty tables ata restaurant, when there is adequate staff to serve the tables, is alsoa lost revenue opportunity.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows one illustrative embodiment of a deal presenter computingsystem in operation within for-hire vehicle.

FIG. 2 shows an embodiment of a deal presenter computing system affixedto the roof of for-hire vehicle and in communication with a consumercomputing device.

FIG. 3A is a block diagram illustrative of one embodiment of a dealmanager computing system in communication over a network with a dealpresenter computing system, a vendor computing system, a paymentprocessor computing system, a reservation and dispatch computing systemand a for-hire vehicle which may comprise one or more computing systemscontrolling its operation.

FIG. 3B is a block diagram illustrative of one embodiment of a dealmanager computing system in communication over a network with a dealpresenter computing system, a vendor computing system, a paymentprocessor computing system, and a for-hire vehicle which may compriseone or more computing systems controlling its operation. The dealmanager computing system of FIG. 3B comprises a reservation and dispatchmodule.

FIG. 4 is a flowchart illustrating a high level view of the lifecycle ofa deal.

FIG. 5 is a block diagram illustrating the temporal flow of data for thelifecycle of a deal through deal definition through deal confirmationbetween a deal presenter computing system, a vendor computing system, apayment processor computing system, a reservation and dispatch computingsystem and a for-hire vehicle which may comprise one or more computingsystems controlling its operation.

FIG. 6 is an illustrative screenshot showing one embodiment of a vendorregistration user interface.

FIG. 7 is an illustrative screenshot showing one embodiment of an offerdetail user interface.

FIG. 8 is an illustrative screenshot showing one embodiment of a mediaupload user interface.

FIG. 9 is an illustrative screenshot showing one embodiment of ageographic restriction user interface.

FIG. 10 is an illustrative screenshot showing one embodiment of a userinterface for updating a predefined deal using a mobile application.

FIG. 11 is an illustrative screenshot showing one embodiment of a dealbeing displayed on a deal presenter computing system.

FIG. 12 is an illustrative screenshot showing one embodiment of a userinterface for selecting a category of deals thereby allowing a consumeror passenger to filter deals based on category.

FIG. 13 is an illustrative screenshot showing available deals in aselectable list view.

FIG. 14 is an illustrative screenshot showing one embodiment of an ageverification user interface.

FIG. 15 is an illustrative screenshot showing one embodiment of apayment information user interface.

FIG. 16 is an illustrative screenshot showing one embodiment of a dealconfirmation user interface.

FIG. 17 is an illustrative screenshot showing one embodiment of a dealbeing displayed on a deal presenter computing system that is a mobiledevice.

FIG. 18 is an illustrative screenshot showing one embodiment of a dealvalidation user interface.

FIG. 19 is a flow chart depicting the process flow of one embodiment ofa deal manager computing system.

FIG. 20 is a flow chart depicting the process flow for one embodiment ofa deal presenter computing system.

FIG. 21 is a flow chart depicting one illustrative example of decisionprocess for displaying a deal.

FIG. 22 illustrates an embodiment of a deal manager computing system.

FIG. 23 is a block diagram illustrative of one embodiment of a dealmanager computer system.

FIG. 24 illustrates a flow chart for a method for promoting a deal usinginformation related to a promoter and calculating compensatory benefitfor promotional efforts.

FIG. 25 is a flow chart depicting an embodiment of a method ofprocessing a deal and compensating a promoter therefore.

FIG. 26 is a screenshot showing an embodiment of a promoter-registrationuser interface.

FIG. 27 illustrates an embodiment of a portable promoter registrationsystem in accordance with one or more embodiments of the presentdisclosure.

FIG. 28 illustrates an embodiment of a promoter identifier communicationtool.

FIG. 29 illustrates an embodiment of an electronic device utilizing adeal service downloadable application.

FIG. 30 is an illustrative screenshot showing an embodiment of a dealpurchase user interface including a promoter identifier input field.

FIG. 31 illustrates an embodiment of a promoter contacting system inaccordance with one or more embodiments of the present disclosure.

FIG. 32 is a flow chart depicting an embodiment of a method ofregistering and compensating a promoter in a deal service system.

DESCRIPTION OF EMBODIMENTS

Embodiments of the disclosure will now be described with reference tothe accompanying figures, wherein like numerals refer to like elementsthroughout. The terminology used in the description presented herein isnot intended to be interpreted in any limited or restrictive manner,simply because it is being utilized in conjunction with a detaileddescription of certain specific embodiments of the disclosure.Furthermore, embodiments of the disclosure may include several novelfeatures, no single one of which is solely responsible for its desirableattributes or which is essential to practicing the embodiments of thedisclosure herein described.

In order for vendors offering entertainment options to maximize theirrevenue opportunity when dealing with a time, location and quantitysensitive asset, an opportunity arises to advertise, for a short periodof time, the entertainment option at a discount. Furthermore, passengersof FHVs are a good target demographic for vendors; passengers are oftentravelers from out of town and may be looking for interesting andinexpensive entertainment options. The present disclosure recognizesthis opportunity and that it is advantageous for vendors to offerdiscounted rates for their entertainment options to passengers of FHVsas they may be likely to purchase the offer at the discounted rate.Further, additional value may advantageously be added by including thefare to the venue in the discounted rate. It may also be advantageousfor drivers of FHVs, or other individuals or entities, to beincentivized to promote offers to their passengers, customers, orwhomever is within their sphere of contact. Furthermore, vendors mayhave an interest in receiving information related to the promotionalactivities of such individuals or entities. For example, a vendor maywish to provide some sort of benefit or promotional material to a subsetof FHV drivers based on transactional or purchase data associated withthe drivers' promotional activities.

Accordingly, embodiments of the present disclosure describe systems andmethods for integrating product and service discounting with requestsfor the reservation and dispatch of for-hire vehicles. In oneembodiment, a deal manager computer system (or “deal manager”) managesdeals offered by vendors and receives promotional offer (or “deal”) datafrom a vendor computer system. The vendor computer system mayadvantageously permit the entry of the promotional offer data though theuse of a web page or other user interface. Based on the receivedpromotional offer information, the deal manager computer systemgenerates a deal, or offer, which is then communicated to a dealpresenter computer system that displays the deal. Once a consumerpurchases the deal, the deal manager computer system receives anotification of acceptance of the deal, or promotional offer. Theacceptance may include location data and payment data. The deal manageruses the location data to reserve and dispatch an FHV to pick up theperson who accepted the deal, or to modify the trip information for acurrent passenger of an FHV. The deal manager computer system uses thepayment information to process payment for the deal. In addition, thedeal manager computer system may also communicate a confirmation messageto the deal presenter computer system and may communicate a confirmationmessage to the vendor computer system. The confirmation message to thedeal presentation computer system may include a voucher number, code, orscanable image that may be used to validate the deal with the vendor andthe driver of the dispatched for-hire vehicle, if necessary. Theconfirmation message may also include pick-up location informationinforming the consumer as to where a for-hire vehicle may pick them up.Once the consumer arrives at the venue of the vendor who offered thedeal, the vendor may validate the purchased deal

In another embodiment, a deal presenter computer system is installed ina for-hire vehicle. The deal presenter computer system comprises adisplay that is affixed to the for-hire vehicle and a point-of-saleterminal for accepting payment instruments such as credit cards. Thedeal presenter computer system receives promotional offers (or “deals”)from a deal manager computer system that manages deals for one or morevendors. The received deals are shown on the display. A consumer (or“user”) may select one or more of the received deals and the dealpresenter computer system may accept input indicating an acceptance ofthe deal. The deal presenter computer system may also accept paymentinformation through the point-of-sale terminal. The promotional offercomputer system may then transmit the acceptance and payment informationto the deal manager computer system. The deal manager computer systemmay then process the received payment information and process anotification for the for-hire vehicle. The notification may containlocation information associated with the vendor so that the for-hirevehicle computer system (or “trip computer”) may update the tripinformation associated with the passenger's current trip and route thefor-hire-vehicle to the vendor location.

In another embodiment, transactional data relating to the promotionalactivities of one or more drivers of FHVs (meaning, promoters) ismaintained for various purposes. For example, such information mayprovide a mechanism for determining when and how to compensate promotersfor promotional activities. Furthermore, in an embodiment, a systemprovides a means for vendors to receive transactional data and conveybenefits and or promotional information to one or more promoters inresponse to receiving such data.

FIGS. 1 and 2 show two illustrative embodiments of deal presentercomputer systems (“deal presenter”). The discussion of FIGS. 1 and 2 ismeant to provide the reader with an overview of the systems and methodsdescribed herein and should not be construed as limiting in any way. Thefunctionality described with respect to FIGS. 1 and 2, and throughoutthis application, may be embodied in various ways and still achieve thesame desired result.

FIG. 1 illustrates one embodiment of a deal presenter 100 in operationwithin for-hire vehicle 120. In the illustrative embodiment of FIG. 1,deal presenter 100 may be connected to the back of the front seat of FHV120. Deal presenter 100 may receive a plurality of advertisements, ordeals, for special rates that may be offered by a vendor. For example,deal presenter 100 may receive a deal for providing a special rate, suchas $20 off, for a variety show, or it may provide a 30% discount at anupscale restaurant at a particular time. Once the deal is received, dealpresenter 100 advantageously displays the deal on display 103 so thatpassenger 115 may view it. The deal may include information related tothe offer that may entice passenger 100 to accept the deal. For example,if the deal is for a variety show, favorable reviews of the show may beincluded in the deal information. For events with fixed seating, thedeal may include seating location information, or may include the optionto select from the seats available at the deal price. The deal may alsoinclude information related to the regular price of an event so thatpassenger 115 may know the quality of the current deal being offered tohim. For example, if the deal is for one ticket to a show for $50,display 103 may provide information to passenger 115 that the usualprice for the show is $100. Various other types of information may beshown on display 103 that may entice or persuade passenger 115 to acceptthe deal.

Display 103 may be, in some embodiments, a touchscreen that allows forpassenger 115 to make input choices by touching display 103. Forexample, display 103 may generate graphical buttons for viewing anotherdeal, accepting a deal, or inputting personal information upon acceptinga deal. In some embodiments, instead of a touchscreen, display 103 mayhave a separate input device, such as a keyboard, attached to it so thatdeal presenter 100 may accept user input choices from passenger 115.Examples of the various user interfaces that may be shown on display 103will be discussed below in greater detail with respect to FIGS. 13-17.

When passenger 115 wishes to accept a deal, the passenger may provideinput to deal presenter 100 indicating acceptance of the deal. Forexample, display 103 may be a touchscreen, that generates an “accept”button that passenger 115 touches to accept the deal. By way of furtherexample, deal presenter 100 may comprise an input button housed on theexternal surface of the deal presenter unit 100 thereby allowingpassenger 115 to accept a deal by depressing the button. Once the dealhas been accepted, deal presenter 100 will process the deal acceptanceand request payment from passenger 115. Payment may be made, forexample, with a credit card. The embodiment of FIG. 1 illustrativelyshows one method of accepting payment, that is point-of-sale (“POS”)terminal 106. POS terminal 106 may be connected to deal presenter 100and may accept a swipe from a credit card, debit card, gift card, orother form of payment as input. Deal presenter 100 may then process thepayment information as described further with respect to FIG. 5 below.

In some embodiments, transportation to the venue providing the deal isincluded in the purchase price. That is, once passenger 115 accepts thedeal and pays the purchase price, FHV 120 will change the passenger's115 destination from her original destination to the venue offering thedeal. In one embodiment, passenger 115 may be en route to a differentlocation and once she accepts the deal, deal presenter 100 maycommunicate with trip computer system 125 to change the trip informationto indicate that passenger 115 will now be traveling to the venueoffering the deal. For example, passenger 115 may be traveling in FHV120 en route to her hotel. Deal presenter 100 may then display a deal togo to a show. Passenger 115 accepts the deal, which includestransportation to the show. Once passenger 115 accepts and pays for thedeal, deal presenter 100 may then communicate with trip computer system125 to update the destination information and change it from thepassenger's hotel, to the location of the show. The FHV would thenchange the passenger's desired destination the passenger from the hotelto the show. In one embodiment, deal presenter 100 is directly connectedto trip computer 125 and updates to the passenger's trip occur throughcommunications between deal presenter 100 and trip computer 125. Inother embodiments, deal presenter 100 may send notification of the dealacceptance to deal manager 300 (discussed in FIG. 3A) which may thensend a message to FHV 120 to update the passenger's trip information intrip computer system 125. Deal presenter 100 may, as discussed ingreater detail below, adjust the offer price of the deal so that thecurrent fare accumulated by passenger 115 is included within the deal.

Turning now to FIG. 2, another embodiment of deal presenter 100 is shownwherein deal presenter 100 is affixed to the roof of FHV 120 (“FHV-topdisplay”). The FHV-top-display may be, for example, a programmable LCDscreen that may advantageously display one or more deals on a rotatingbasis. For example, if deal presenter 100 receives two deals, a firstoffering 50% off at a steakhouse, and a second offering show tickets for$20, deal presenter may display the steakhouse offer for sixty seconds,display the show offer for sixty seconds and then display the steakhouseoffer again. Through the use of the FHV-top-display, deal presenter mayadvantageously attract consumer 215 who may be walking on the street.Advantageously, deal presenter 100 may provide network connection point230, which may be a wireless access point, or mobile hot-spot, so thatconsumer 215 may accept a deal using a Wi-Fi enabled mobile device 210,for example. In one embodiment, deal presenter 100 may display a dealalong with connection information that consumer 215 may use to connectmobile device 210 to deal presenter 100 so that consumer 215 may acceptthe deal. For example, in the illustrative embodiment of FIG. 2,consumer 215 may connect to deal presenter 100 through the “Wifi-Beta”wifi network, Once connected, mobile device 210 may include a graphicaldisplay that may show user interfaces comprising deals and input meansthat allows consumer 215 to accept deals. The types of user interfacesshown on consumer computing device 215 may be similar to the userinterfaces described with respect to FIGS. 11-17.

Once consumer 215 accepts the deal displayed by deal presenter 100,consumer 215 may pay for the deal with mobile device 210. For example,consumer 215 may enter their credit card information using the inputdevices and displays that are part of mobile device 210. In someembodiments, an acceptance message may then be sent from mobile device210 to network connection point 230 of deal presenter 100. Upon receipt,deal presenter 100 may, as described in greater detail below, send anacceptance message to deal manager 300 (see FIG. 5). Deal manager 300may manage payment processing associated with the deal and may interfacewith reservation and dispatch computing system 350 so thattransportation for consumer may be arranged, for example through makinga for-hire vehicle request on behalf of the consumer. (In oneembodiment, deal manager 300 may comprise modules that handle thereservation and dispatch of FHVs as shown in FIG. 3B). In someembodiments, deal presenter 100 may be connected to trip computer 125,and once deal presenter 100 receives notification that a deal has beenaccepted, it may send a dispatch message to trip computer 125 so thatthe FHV may be directly dispatched to pick up consumer 215 and transporthim to the venue offering the deal.

In one embodiment, consumer 215 may install a dedicated deal applicationon mobile device 210. The deal application may be configured to receivedeal offers and display them on screen so that consumer 215 may acceptthem, thereby making consumer computing system 210 an embodiment of dealpresenter 100. The deal application may advantageously allow forconsumer 215 to browse currently available deals, and may permitconsumer 215 to accept a deal without being in the presence of FHV 120.Once consumer 215 accepts the deal through the application, mobiledevice 210 (acting as a deal presenter 100) may then communicate theacceptance to deal manager 300. Deal manager 300 may then reserve an FHVto transport the consumer 215 to venue offering the deal. In someembodiments, deal manager 300 may be in communication with reservationand dispatch computing system 350. In other embodiments, deal manager300 may comprise modules that handle the reservation and dispatch offor-hire vehicles (as shown with respect to FIG. 3B). In one embodiment,deal presenter 100 may leverage the location features of consumercomputing device to communicate the location of consumer 215 whenreserving the FHV. For example, if consumer computing system 210 is amobile phone, deal presenter 100 may use the GPS chip of the mobilephone to communicate geospatial location information to the FHVreservation computing system.

FIG. 3A is a block diagram illustrative of one embodiment of a dealmanager computer system (“deal manager”) 300 in communication overnetwork 380 with a deal presenter computer system (“deal presenter”)100, a vendor computer system (“vendor system”) 310, a payment processor320, a reservation and dispatch computer system (“reservation anddispatch”) 350 and for-hire vehicle 120 (“FHV”), which may comprise oneor more computing systems controlling its operation. While FIG. 3A mayillustrate deal manager 300, deal presenter 100, vendor system 310,payment processor 320, reservation and dispatch 350 and FHV 120 asseparate computing systems or modules, the functionality provided for inthe systems and modules of FIG. 3A may be combined into fewer componentsand modules or further separated into additional components and modules.For example, while deal manager 300 and reservation and dispatch 350 areshown as separate computing systems, their respective functionality maybe embodied as modules within the same computing system, as shown inFIG. 3B. By way of further example, the functionality of deal presenter100 may be split among more than one computing system as is shown in theillustrative embodiment of FIG. 3A. In addition, while the blocks ofFIG. 3A are described in the singular for ease of reference, embodimentsmay include more than one of each block. For example, in one embodiment,there may be a plurality of deal presenters 100 (as shown in FIG. 5) orthere may be a plurality of FHVs 120.

In one embodiment, deal manager 300 is a computing system responsiblefor managing deals. Deal manager 300 advantageously provides interfacesfor vendors to define deals and may accept deal definitions created byvendors. Deal manager 300 also handles the publication of deals to dealpresenter 100 and may monitor the currently defined deals forpublication. For example, deals may be time restricted, that is, theymay only be offered during a fixed period of time defined by a starttime and an end time. For example, a deal may run on Oct. 1, 2011 from 5PM (start time) to 8 PM (end time). Deal manager 300 may execute aprocess that checks the currently defined deals in the system andpublishes them to deal presenter 100 at the start time of the deal. Thedeal manager advantageously is in periodic communication with the vendorsystem to confirm that the deals listed are still current, and when adeal is sold the vendor system is updated. The frequency of thisperiodic communication will depend on the type of deal. For example ifseats to a show are being offered then the communication with the vendorsystem needs to be sufficient to prevent the sale of two identicalseats. It is contemplated that this communication can be accomplishedautomatically without the need for human intervention. The Deal manager300 may also handle the acceptance of the deal. Once deal manager 300receives notification from deal presenter 100 that a deal has beenaccepted, deal manager 300 may interface with reservation and dispatch350 to request a FHV, and it may also interface with payment processor320 to process payment. Deal manager 300 may also maintain historicaldata of past deal campaigns for reporting purposes to vendor system 310.

In one embodiment, deal manager 300, is a computing system that is IBM,Macintosh or Linux/Unix compatible. Deal manager 300 may, in someembodiments, include one or more central processing units (“CPU”) 301,which may include one or more conventional or proprietarymicroprocessors. Deal manager 300 may further include memory 302, suchas random access memory (“RAM”) for temporary storage of information andread only memory (“ROM”) for permanent storage of information, and datastore 303, such as a hard drive, diskette, or optical media storagedevice. In certain embodiments, data store 303 stores data needed formanaging and maintaining deals. In other embodiments, data store 303might store historical deal information. Embodiments of data store 303may store data in databases, flat files, spreadsheets, or any other datastructure known in the art. Typically, the modules of deal manager 300are in communication with one another via a standards based bus system.In different embodiments, the standards based bus system could bePeripheral Component Interconnect (PCI), Microchannel, SCSI, IndustrialStandard Architecture (ISA) and Extended ISA (EISA) architectures, forexample. In another embodiment, deal manager 300 leverages computing andstorage services available over the Internet (cloud computing).

Deal manager 300 is generally controlled and coordinated by operatingsystem software, such as the Windows 95, 98, NT, 2000, XP, Vista, Linux,SunOS, Solaris, PalmOS, Blackberry OS, or other compatible operatingsystems. In Macintosh systems, the operating system may be any availableoperating system, such as MAC OS X. In another embodiment, deal managermay be controlled by a proprietary operating system, that is one thathad been custom made for the purposes of embodying the systems andmethods described herein. Conventional operating systems control andschedule computer processes for execution, perform memory management,provide file system, networking, and I/O services, and may provide auser interface, such as a graphical user interface (“GUI”) for display,among other things.

Deal manager 300 may also include one or more commonly available I/Odevices and interfaces 304, such as for example, a printer, buttons, akeyboard, a LED display, a monitor, a touchpad, a USB port, a RS 232port and the like. In one embodiment, I/O devices and interfaces 304include one or more display devices, such as a monitor, that allows thevisual presentation of data, such as fare and operation data, to a user.In the embodiment of FIG. 3A, I/O devices and interfaces 304 provide acommunication interface to various external devices. For example, in theillustrative embodiment of FIG. 3A deal manager 300 is in communicationwith network 380, such as any combination of one or more LANs, WANs, orthe Internet, for example, via a wired, wireless, or combination ofwired and wireless, connections via a network interface of I/O devicesand interfaces 304. The communications interface may also include, forexample, ports for sending and receiving data such as a USB port or anRS 232 port.

Deal manager 300 may also include several application modules that maybe executed by CPU 301. The software code of the modules may be storedon a tangible computer-readable medium such as for example, RAM or ROM.More particularly, the application modules may include deal definitionmodule 305 and deal publishing module 306.

In general, the word module, as used herein, refers to logic embodied inhardware or firmware, or to a collection of software instructions storedon a non-transitory and/or tangible computer-readable storage, possiblyhaving entry and exit points, written in a programming language, suchas, for example, C, C++, C#, or Java. A software module may be compiledand linked into an executable program, installed in a dynamic linklibrary, or may be written in an interpreted programming language suchas, for example, BASIC, Perl, or Python. It will be appreciated thatsoftware modules may be callable from other modules or from themselves,and/or may be invoked in response to detected events or interrupts.Software modules may be stored in any type of computer-readable storage,such as a memory device (for example, random access, flash memory, andthe like), an optical medium (for example, a CD, DVD, BluRay, and thelike), firmware (for example, an EPROM), or any other storage medium.The software modules may be configured for execution by one or more CPUsin order to cause computing systems described herein, such as dealpresenter 100 and deal manager 300, to perform particular operations.

It will be further appreciated that hardware modules may be comprised ofconnected logic units, such as gates and flip-flops, and/or may becomprised of programmable units, such as programmable gate arrays orprocessors. The modules described herein are preferably implemented assoftware modules, but may be represented in hardware or firmware.Generally, the modules described herein refer to logical modules thatmay be combined with other modules or divided into sub-modules despitetheir physical organization or storage.

Deal manager 300 may include, in some embodiments, deal definitionmodule 305. Deal definition module 305 may comprise code executed by CPU301 that is responsible for the definition of deals. For example, dealdefinition module 305 may generate user interfaces, such as theillustrative user interfaces of FIGS. 6-10, that may be used by a vendorto define a deal. Deal definition module 305 may also handle theprocessing of deals received by vendor systems 310 and store dataassociated with the deals in data store 303. Deal definition module 305may also retrieve deal related data and populate it in the userinterface so that vendor may modify deal information. In someembodiments, deal definition module 305 may be programmed with standardoptions or standard deal parameters that may be used by vendors tofacilitate deal definition or provide a template for vendors to define adeal. For example, deal definition module 305 may maintain a list ofpresentation device types, such as, in-vehicle display, for-hire vehicledisplay or mobile application so that a vendor may select thepresentation devices on which the vendor's defined deal will bepublished.

In some embodiments, deals may be defined as part of an advertisingcampaign, that is, a vendor may define a series of deals it may offer,or standard deals it may offer on a regular basis, that are related tothe same set of condition parameters triggering the deal offer. Forexample, if a vendor offers a show in a venue that seats 200 people, thevendor may define a standard deal offering tickets at 50% off if lessthan 150 seats have been sold by thirty minutes before the show'sscheduled start time. Alternatively, a steakhouse may define an all youcan eat campaign, that offers a deal for an all you can eat buffet at aspecial price on Tuesdays. Deal definition module 305 may provide userinterfaces or other means for allowing vendors to define a dealcampaign. Deal definition module 305 may also comprise code forexecution that stores and retrieves data related to vendor campaign.

In one embodiment, vendor system 310 may launch a predefined deal bysending a message to deal manager 300, or more specifically to dealdefinition module 305, to launch the particular deal. For example, if avendor predefines a standard deal offering an all you can eat buffet for$10, the vendor system 310 may launch the predefined deal by sending acommand to deal manager 300 that the deal should be executedimmediately. Vendor system 310 may command the deal manager 300 througha web interface provided by deal manager 300. In other embodiments,vendor system 310 may have installed on it a deal queue application thatlists the vendor's predefined deals and may contain options forlaunching the deal. The application may be a mobile application as shownin FIG. 10 for example, or in other embodiments, may be an applicationexecuted on a desktop, laptop, tablet, or other general purposecomputing device. In some embodiments, the vendor may define its deal torun for a specific time interval. For example, an all you can eat buffetfor $10 may be offered for 45 minutes once it launches. In anotherembodiment, the deal queue application may provide commands for startingand stopping a deal thereby allowing the vendor flexibility to controldeal presentation based on the vendor's needs. For example, a vendoroffering an all you can eat buffet may be not be servicing customers atmaximum capacity and may therefore wish to offer a 40% discount on thebuffet. The vendor may launch the deal queue application and select thepredefined deal offering the 40% discount. Using the deal queueapplication, the vendor system 310 may send a command to deal manager300 to begin publishing the deal. The deal may result in an increase inbusiness that exceeds the capacity of the vendor. The vendor system maythen re-launch the deal queue application, select the currently runningdeal, and issue a command to deal manager 300 to stop offering the deal.

In another embodiments, deal definition module 305 advantageously allowsvendor systems to define deal triggers. A deal trigger is a predefineddeal with deal offer conditions that must be satisfied before the dealis to be published. The deal offer conditions may relate to the time thedeal is offered, the location of where the deal is offered, the currentinventory of the vendor, a combination of conditions, or other dealconditions that may be defined by the vendor. For example, a vendor maywish to fill most of its seats for a show prior to show time. The vendormay create a predefined deal that offers the show tickets at 50% off.The vendor may create deal offer conditions associated with predefineddeal that will trigger the deal once the conditions are satisfied. Thedeal conditions may be, for example, “(1) if there are less than 100seats sold, (2) at 30 minutes before show time, (3) offer the deal forthe next 40 minutes.” Once interest is shown in particular seats forexample by making the appropriate selection through the deal presenter100 then the seats are held for a limited time (maybe 5 to 10 minutes)to give the customer the opportunity to complete the payment process.The deal conditions may also be location based. For example, hotels mayonly wish to present deals to passengers being picked up at the airport,train station, or bus station. In such instances, the vendor mayassociate a deal condition with their predefined deal indicating thedeal should only be presented on deal presenters that are at theairport, train station or bus station. The vendor may create locationbased deal offer conditions using, for example, a map interface such asthe map interface shown in FIG. 9.

In some embodiments, deal manager 300 may comprise deal publishingmodule 306. Deal publishing module 306 advantageously comprises codethat when executed handles the publication of deals and processing ofdeals once published. For example, deal publishing module 306 mayexecute a looped process that checks the contents of data store 303 todetermine if any defined deals based on time should be published, or ifany deal conditions related to deal triggers have been satisfied. Dealpublishing module 306 may check the current time and then compare thatto the publishing time of a particular deal. If deal publishing module306 determines a deal should be published, it may then send a messagecontaining the deal, or a “deal packet” out over network 380 that may beconsumed by deal presenter 100. Deal packets may contain data related tothe deal, such as price of the deal, details of the deal (time, locationand/or event information about the deal), and display and formattinginformation about the deal (such as, for example, HTML code defining howthe deal should be displayed on deal presenter 100). The deal packet mayalso contain code for execution upon passenger 115 or consumer 215accepting the deal. The code may contain, for example, networkinformation defining where the data should be sent.

In some embodiments, deal publishing module 306 may take a “snapshot” ofthe current passengers riding in FHVs. The snapshot may includeinformation and data describing the passengers at a particular instantin time. For example, the snapshot may include information about wherepassengers where picked up or where they may be dropped off andidentification information identifying the deal presenter 100 that isaffixed to the FHV in which the passengers are traveling. The dealpublishing module 306 may then compare the information and data from thesnapshot to potential customer attributes defined by a vendor which maydefine to whom the vendor would like to present deals. If theinformation and data from the snapshot indicates that some passengersmay be interested in the deal, deal publishing module 306 may publish adeal to those passengers. For example, suppose a vendor wants to attractpassengers who are staying at luxury hotel. The vendor may set up acustomer attribute that indicates they would like to present deals tothose passengers who were picked up at the luxury hotel. When there is aneed to offer deals, deal publishing module 306 may take a snapshot ofthe current passengers of FHVs in a location close to the venue of thevendor. If any of those passengers were picked up from the luxury hotel,deal publishing module 306 may publish a deal to those passengers.

In addition, deal publishing module 306 advantageously processesaccepted deals. As described in greater detail below, deal publishingmodule 306 generally processes payment, generates FHV fulfillments(which may include reserving a FHV or communicated updated tripinformation to a FHV), generates voucher information, sendsconfirmations, and then waits for a message indicating a voucher hasbeen redeemed. The processing involved upon deal acceptance is discussedin greater detail with respect to FIG. 19.

Returning to FIG. 3A, deal presenter 100 may be computing system that inresponsible for receiving deals, displaying deals and managing theconsumer/passenger end of a deal transaction. For example, dealpresenter 100 may receive a deal published by deal manager 300. Oncereceived, deal presenter 100 may display the deal so that passenger 115or consumer 215 may view it. If consumer 215 (or passenger 115) decidesto purchase the deal, deal presenter 100 may accept an input criteriaindicating deal acceptance and may also collect data such as consumer215's name, address, current location and payment instrument (such as acredit card) information. Deal presenter 100 may then transmit thatinformation to deal manager 300. Deal presenter 100 may also receive aconfirmation message and display the message along with voucherinformation for consumer 215.

In one embodiment, deal presenter 100, is a computing system that isIBM, Macintosh or Linux/Unix compatible. Deal manager 300 may, in someembodiments, include one or more central processing units (“CPU”) 101,which may include one or more conventional or proprietarymicroprocessors. deal presenter 100 may further include memory 102, suchas random access memory (“RAM”) temporary storage of information andread only memory (“ROM”) for permanent storage of information.Typically, the modules of deal manager 300 are in communication with oneanother via a standards based bus system. In different embodiments, thestandards based bus system could be Peripheral Component Interconnect(PCI), Microchannel, SCSI, Industrial Standard Architecture (ISA) andExtended ISA (EISA) architectures, for example. In another embodiment,deal manager 300 leverages computing and storage services available overthe Internet (cloud computing).

As described above, deal presenter 100 may be a dedicated computingsystem specifically designed to display deals. For example, dealpresenter 100 may be a custom in-vehicle display, or it may be computingsystem that is part of a FHV-top display. In other embodiments, dealpresenter 100 may be an application module that executes on ageneral-purpose computer such as a mobile phone, tablet computingdevice, laptop computer or desktop computer. In other embodiments, dealpresenter 100 may be a module that executes with another applicationsuch as a web browser.

Deal presenter 100 is generally controlled and coordinated by operatingsystem software, such as the Windows 95, 98, NT, 2000, XP, Vista, Linux,SunOS, Solaris, PalmOS, Blackberry OS, iOS, or other compatibleoperating systems. In Macintosh systems, the operating system may be anyavailable operating system, such as MAC OS X. In another embodiment,deal manager may be controlled by a proprietary operating system, thatis one that had been custom made for the purposes of embodying thesystems and methods described herein. Conventional operating systemscontrol and schedule computer processes for execution, perform memorymanagement, provide file system, networking, and I/O services, and mayprovide a user interface, such as a graphical user interface (“GUI”) fordisplay, among other things.

Deal presenter 100 may also include one or more commonly available I/Odevices and interfaces 104, such as for example, a printer, buttons, akeyboard, a monitor, a touchpad, a USB port, a RS 232 port and the like.In the embodiment of FIG. 3A, I/O devices and interfaces 104 provide acommunication interface to various external devices. For example, in theillustrative embodiment of FIG. 3A deal presenter 100 is incommunication with network 380, such as any combination of one or moreLANs, WANs, or the Internet, for example, via a wired, wireless, orcombination of wired and wireless, connections via a network interfaceof I/O devices and interfaces 104. The communications interface may alsoinclude, for example, ports for sending and receiving data such as a USBport or an RS 232 port.

Deal presenter 100 may also include several application modules that maybe executed by CPU 301. The software code of the modules may be storedon a tangible computer-readable medium such as for example, RAM or ROM.More particularly, the application modules may include presentationmodule 105 and POS terminal 106.

In one embodiment, presentation module 105 may include code thatdetermines whether deals should be displayed and may also contain codefor generating user interfaces that will be shown on display 103. Insome embodiments, the decision logic that determines whether a dealshould be displayed may take into account the current time, the currentlocation of deal presenter 100, the current fare accumulated bypassenger 115, and demographic information about passenger 115 orconsumer 215. Presentation module 105 may maintain in memory 102 a datastructure (the “monitor queue”) that stores all published deals itreceives and may periodically review the deals in the monitor queue todetermine if it should display the deal. The manner in which the monitorqueue and the presentation module 105 operate to determine if a dealshould be presented is explained in connection with FIG. 21.

In some embodiments, deal presenter 100 may be connected to or include aGPS receiver. The GPS receiver may, for example, be an external GPSreceiver that provides GPS coordinates to deal presenter 100 via I/Odevices and interfaces 104. In another embodiment, deal presenter maycomprise an on board GPS receiver that communicates with the modules andother components of deal presenter 100. In some embodiments,presentation module 105 may correlate received GPS coordinates withknown points of interest for the purpose of determining whether todisplay a deal. For example, presentation module 105 may contain logicfor correlating a GPS coordinate with the airport or a particularhigh-end hotel.

In one embodiment, deal presenter 100 may include POS terminal 106. POSterminal 106 may include hardware and software capable of accepting apayment instrument, such as credit card, debit card or gift card. Insome embodiments POS terminal 106 may be a “card swipe” device, forexample, a device that reads the payment instrument when a user runs themagnetic stripe of the payment instrument through a grove of POSterminal 106. In another embodiment, POS terminal may include a keypadwhere a user may input a payment instrument account number. Manycommercially available POS terminals exist and such POS terminals may beconnected to deal presenter 100 by any means known in the art forconnecting POS terminals to computing systems, such as for example, USB.

Turning back to FIG. 3A, reservation and dispatch 350 may be a computingsystem that is responsible for the reservation and dispatch of FHVs. Inone embodiment, reservation and dispatch 350 receives messages from dealmanager 300 to request a FHV. The reservation message may contain, forexample, the time a FHV should be dispatched, the location where theconsumer is to be picked up, and a fixed fare amount for travel. In someembodiments, the FHV should be dispatched immediately, while in otherembodiments, the request may be for some time in the future. Once arequest message is received, and the time to dispatch a FHV hasoccurred, reservation and dispatch 350 may send a dispatch message toFHV 120 so that consumer 215 may be picked up at their current location,or a their reserved location, which ever is appropriate for the accepteddeal.

In some embodiments, FHV 120 may include dispatch module 125 which hasbeen configured to handle receiving dispatch messages. Dispatch module125 may be, in some embodiments, a dedicated dispatch computing system.In other embodiments, it may be an application module running on ageneral purpose computer such as, for example, a mobile phone, tablet,laptop, or other general purpose computing device suitable forin-vehicle use. FHV 120 may also contain a meter, that is, a device usedfor calculating and reporting fares. In some embodiments, the meter ofFHV 120 is advantageously connected to deal presenter 100 to facilitatethe accurate calculation of deals based on the current fare accumulatedby passenger 115. FHV 120 may also contain a POS terminal for acceptingcredit card payments for trip fares. The POS terminal may also beconnected to deal presenter 100 so that passenger 115 may use the POSterminal to pay for deals in addition to paying for trip fares.

Vendor system 310 may be a computing system that is owned and operatedby a vendor that is offering a deal. Vendor system 310 advantageouslyincludes a web browser allowing vendors to register their business (forexample, using the illustrative user interface of FIG. 6), or to definedeals (for example, using the illustrative user interfaces of FIGS.7-9). Vendor system 310 may, in some embodiments, be a mobile device,tablet, laptop of desktop. In addition to a web browser facilitatingdeal definition, vendor system 310 may also contain a dedicatedapplication that is configured to execute on vendor 310 and allow fordeal definition using user interface similar to show in FIGS. 6-10.

In some embodiments, vendor system 310 may also include a validationmodule. The validation module advantageously handled voucher redemption.The validation module may interface with a peripheral device such as UPCcode or QR code scanner. In some embodiments, vendor system 310 may be amobile device, such as a cell phone, that may be equipped with a QR codereader. In such embodiments, the validation module may interface withthe QR code reader to receive voucher data from the QR code. In otherembodiments, the validation module may interface with a keyboard. A userof vendor system 310 may enter in a voucher number, or serial number,for the voucher using the keyboard in order to redeem the voucher. Thekeyboard may, in some embodiments, be a virtual keyboard displayed on atouchscreen device such as a tablet computing device. Vendor system 310may also interface with an interactive voice response (IVR) applicationin order to validate vouchers. A user may, for example, call the IVRapplication and read the voucher or serialized identifier over the phonein order to validate the voucher.

Payment processor 320 may, in some embodiments, be a computing systemoperated by a party appointed by a merchant to handle credit cardtransactions. For example, payment processor 320 may be a third partyentity that handles the credit card transactions entered into POSterminal 106. Generally, payment processor 320 may expose an applicationprogram interface (API) that permits outside computer systems, such asdeal manager 300, to process credit transactions.

FIG. 3B is a block diagram illustrative of one embodiment of dealmanager 300 in communication over network 380 with a deal presenter 100,vendor system 310, payment processor computing system 320, and for-hirevehicle 120 which may comprise one or more computing systems controllingits operation. In the embodiment of FIG. 3B, deal manager 300 comprisesreservation and dispatch module 350 which performs the functions of thereservation and dispatch computing system 350 of FIG. 3A. For example,reservation and dispatch module 350 may receive reservations for FHVsand dispatch the FHVs according to received reservations. In addition,reservation and dispatch module 350 may update the trip computers of FHV120 if passenger 115 accepts a deal while traveling in FHV 120. Asreferences herein, “reservation and dispatch” may refer to either theembodiment illustrated with respect to FIG. 3A or the embodimentillustrated with respect to FIG. 3B.

FIGS. 4 and 5 illustrate embodiments of the lifecycle and data flow fora deal from its definition to its redemption. FIG. 4 is a flowchartillustrating a high level view of the lifecycle of a deal. FIG. 5 is ablock diagram illustrating the temporal flow of data for the lifecycleof deal from deal definition through deal confirmation.

In FIG. 4, a high level view of the lifecycle of one embodiment of adeal is illustratively described. The high level view of FIG. 4 is meantto provide an overview of the states of a deal. The operationsassociated with each stage of the deal is described in greater detailbelow. The lifecycle of a deal begins in block 410 with the definitionof the deal. Generally, deals may be defined by those offering the dealsuch as vendor. Once defined, the deal is presented at block 420. Dealpresentation typically involves deal manager 300 communicating dealinformation to deal presenter 100. Deal presenter 100 may then displaythe deal. Once displayed, consumer 215 may accept the deal at block 430.Deal acceptance typically comprises the steps of receiving a user inputto accept the deal and deal presenter 100 communicating the acceptanceto deal manager 300. Once accepted, the deal is confirmed at block 440.Generally, a deal is confirmed by processing payment for the deal,generating a voucher that may be redeemed at venue of the vendor andtransmitting the voucher to deal presenter 100, and deal manager 300reserving a FHV for transporting consumer 215 to the venue of the vendorby communicating with reservation and dispatch 350. Finally, at block450, the deal is redeemed at the venue. Redemption may also includevendor system 310 communicating validation or redemption data to dealmanager 300.

The high level view of the deal lifecycle described in FIG. 4 may now beexplained in greater detail using the temporal flow diagram of FIG. 5.FIG. 5 depicts the temporal flow of data between one embodiment of dealpresenter 100, deal manager 300, vendor system 310, a payment processor320, reservation and dispatch 350 and for-hire vehicle 120 (which maycomprise one or more computing systems controlling its operation). Inparticular, the circled numerals of FIG. 5 illustrate the order in whichdata flows between the various components of FIG. 5 according to oneembodiment. In another embodiment, the steps outlined by the circlednumerals may be performed in a different order, and the method mayinclude fewer or additional steps.

Generally, the temporal flow of data starts with step 1 where vendorsystem 310 transmits deal definition data to deal manager 300. Next, atstep 2, deal manager 300 publishes deals to deal presenter 100. At step3, deal presenter transmits a deal acceptance back to deal manager 300.In response, deal manager 300 processes the payment associated with thedeal acceptance at step 4 by transmitting payment information to paymentprocessor 320. At step 5, payment processor 320 transmits a confirmationback to deal manager 300 that the payment transaction was successful.Upon receipt of successful payment processing, deal manager 300, at step6, verifies that the transportation request associated with the deal maybe fulfilled by sending a message to reservation and dispatch 350 toinsure that a FHV is available to transport the consumer 215 to thevenue of the vendor. Once the transportation request has been fulfilled,deal manager 300 transmits a confirmation message containing a voucherfor the deal to deal presenter 100 at step 7, and at step 8 transmits amessage reserving a FHV to reservation and dispatch 350. Reservation anddispatch 350 then automatically transmits a dispatch notice to FHV 120thereby dispatching FHV 120 for picking up the consumer who purchasedthe deal, at step 9. Finally, at step 10, the voucher generated and sentto deal presenter 100 at step 7 is validated and redeemed by vendorsystem 310 by transmitting a redemption message to deal manager 300.

In step 1 of FIG. 5, vendor system 310 sends information defining a dealto deal manager 300. In one embodiment, vendor system 310 may execute acustom client-based computer application allowing for the user of vendorsystem 310 to input data defining a deal. Once the data has beenentered, the client-based computer application may connect to dealmanager 300 and communicate the entered data to deal manager 300,thereby defining the deal. In another embodiment, vendor system 310 mayhave a web browser application installed and deal manager 300 maycomprise a web server that offers web pages to vendor system 310 toinput data defining a deal, thereby allowing vendor system 310 tocommunicate deal definition data to deal manager 300.

FIGS. 6-10 illustrate various user interfaces that may be used to definedeals. The user interfaces of FIG. 6-10 may be web pages or userinterfaces of a computer application that executes on vendor system 310that may be in communication with deal manager 300. The user interfacesof FIG. 6-10 are meant as examples and may include more or less userinterface elements as desired.

In some embodiments, vendors may register with deal manager 300.Registration may facilitate deal definition so that data related to thevendor is shared among the deals its offers thereby allowing for a morestreamlined deal definition process. For example, the address of venueof the vendor may be communicated to deal manager 300 at the time ofregistration. When the vendor submits deals in the future, the addressof the venue need not be entered. FIG. 6 shows one illustrativeembodiment of vendor registration user interface 600. Vendorregistration user interface 600 advantageously includes vendorinformation fields 610. Vendor information fields 610 may include, forexample, a text field for business name entry, a text field for thefirst and last name of the contact of the vendor, the address of thevenue of the vendor and the website of the vendor. Vendor registrationuser interface 600 may also include category drop down list 615 whichallows for the input of the vendor's category. For example, categorydrop down list 615 may include categories for selection such as AdultEntertainment, Hotel/Resort, Clubs, Shows, Restaurants, or othercategories of vendors. The category may be used to filter dealsdisplayed on deal presenter 100 to passenger 115 or consumer 215. Vendorregistration user interface 600 may also include presentation type dropdown 620. Presentation type drop down 620 may include the types of dealpresenters on which the deal will be displayed. For example, a deal maybe presented on a mobile device such as a cell phone, on a FHV-topdisplay or a in-vehicle display. Presentation type drop down 620 mayinclude these deal presentation types, among others. Vendor registrationuser interface 600 may also include vendor information block 630. Vendorinformation block 630 allows for vendor 310 to provide additionalinformation about the vendor's business. Deal manager 300 may use thetext entered into vendor information block 630 to provide additionalservices to the vendor or to target advertisements to the vendor, forexample.

In some embodiments, the data entered into vendor information block 630by the vendor may be used by deal manager 300 to generate targeteddeals. Targeted deals are deals that may be targeted to certainpassengers or consumers based on demographic information or behaviorthat may be gleaned from their use of FHVs or other information. Dataentered into the vendor information block 630 may be used to generatetargeted deals by including some of the data in deals that are generatedand communicated to deal presenter 100. In another embodiment, the dataentered into vendor information block 630 may be used to associate aconsumer category with the vendor and the deals the vendor offers. Aconsumer category may be an indicator of a consumer type. For example, aconsumer category may be “affluent traveler”, “businessman”, “family”,“adult entertainment”, “frequent dinner.” Deal manager 300 may usekeywords entered into vendor information block 630 to create anassociation with a consumer category. For example, if the vendor enters“We are an upscale dinning establishment serving fine French cuisineprepared by a world-class chef,” deal manager may detect the keywords“upscale”, “French cuisine” and “world-class chef” to associate thevendor with the “affluent traveler” consumer category. As the vendordefines deals, the deals may be tagged, or associated with the “affluenttraveler” category. When the deals are published and communicated todeal presenter 100, the “affluent traveler” consumer category may beincluded in the deal information. Deal presenter 100 may then use theconsumer category as part of its decision to display the deal. Forexample, as explained with respect to FIG. 21, deal presenter 100 maydetermine that the current passenger is an “affluent traveler” and as aresult, display the deal. In addition or alternatively the vendor inputscreens may permit the vendor to identify the consumer categories thatthe vendor has decided that it wants to target.

In some embodiments, the vendor may define deals. The definition of adeal may comprise a title, a description, a price, and a retail price.For example, if the deal is for a show called “Great Show”, the titlemay be “Deal on Great Show!”, the description may be “The Great Show isan exciting mix of circus arts set to dramatic classical music”, theprice may be $25 and the retail price may be $60. A deal definition mayalso include custom graphics, images, or videos that allow vendor 310 tocreate an attractive and persuasive deal advertisement for display ondeal presenter 100. In some embodiments, deals may be time restricted,that is, they may only run between a first time and a second time. Insuch embodiments, the deal definition includes the start time and endtime of the deal. The vendor may also restrict the areas where deals mayrun. For example, if the vendor wishes to run their deals on a FHV-topdisplay or on in-vehicle displays, they may limit the display of thedeal to a particular predefined area. In such embodiments, the dealdefinition may also include geospatial parameters that define the areawhere the deal will run.

Deals may be defined by the vendor using user interfaces provided bydeal manager 300, or in other embodiments, by a custom clientapplication executing on vendor 310 that is communication with dealmanager 300. FIG. 7 shows one illustrative embodiment of offer detailuser interface 700 that may be used by the vendor to define a deal.Offer detail user interface 700 may include, for example, text fields705, 710 for inputting the name and header text of the deal. The offerdetail user interface 700 may also include body text area 715. Body textarea 700 may provide a tool bar for formatting and aligning text in thedeal. In some embodiments, body text area 700 may accept HTML code astext thereby allowing vendor 310 to format the text that will bedisplayed in their deal. Body text area may include features that allowbulleted and numbered lists, hyperlink and image dialogs, support acrossweb browsers, or other features known in the art for formatting text.Offer detail user interface 700 may also include presentation type dropdown 720. Presentation type drop down 720 may permit the vendor toselection on what type of deal presenter display the deal will be shown.For example, the presentation type drop down may include options such as“In-vehicle Display”, “Vehicle Top”, “Mobile Device” Or “all of theabove.” Offer detail user interface 700 may also include a product nametext field 725 for inputting a product name. Offer detail user interface700 may also include a retail price text field 730 which may be used tohighlight to passenger 115 or consumer 215 the size of the deal. Forexample, consumer 215 may recognize that a deal is good if the retailprice is $100 and the deal is being offered for $50. In someembodiments, the deal may include an indication that there is a limitedsupply of deals. For example, for a show, a vendor may only offer 10seats to the show as a deal. Text field 735 advantageously allows thevendor to input the number of available deals, or inventory, for thedeal.

In some embodiments, vendor system 310 may upload media such as imagesand/or video so that the deal may be more attractive to those that viewit. FIG. 8 illustrates one embodiment of media upload interface 800which advantageously provides user interface elements for uploadingmedia content to deal manager 300 so that the media may be included inthe defined deals of the vendor. Media upload interface 800 may includea deal duration slider 810 allowing for the vendor to set the durationfor displaying the deal. For example, in the illustrative embodiment ofFIG. 8, the slider may be set so that the deal appears for a durationbetween 0 and 30 seconds. In another embodiment, media upload interface800 may not include a slider, but rather, may include a text field forentering the duration for displaying the deal. Media upload interface 8may also include upload element 820. Upload element 820 may be any userinterface known in the art permitting upload of files to a server.Upload element 820 may provide a “Select” button. When the user clickson the “Select” button, a file system dialog block may appear allowingthe user to navigate to a directory that may contain a media file foruploading. Once the user selects the appropriate media, the name of thefile may appear in text area of upload element 820. In some embodiments,deal manager 300 may only permit files up to a maximum file size. Uploadelement 820 advantageously informs the user of the max file size. Mediaupload interface 800 may also include transition drop down block 830.Transition drop down block 830 may contain a list of standardtransitions from one image of a deal to the next image of the deal. Forexample, transition drop down block 830 may include transitions such asaccordion (simulating the look and feel of an accordion), blinds(simulating the look and feel of horizontal or vertical blinds) or sweep(simulating the look and feel of the deal sweeping in from the top,bottom, left or right). Media upload interface 800 may also includemedia duration slider 840 that allows a user to enter the displayduration for which the media (as opposed to the entire deal) may bedisplayed.

In some embodiments, more than one media may be uploaded and included aspart of deal. For example, a deal may include several still images,several videos, or a mixture of images and videos. Media uploadinterface 800 may include buttons for adding additional media. As mediais added, the vendor may set the transition and the display duration foreach piece of media. In one embodiment, the order the media will bedisplayed to passenger 115 or consumer 215 is based upon the order theuploaded media appears in media upload interface 800. For example, ifimage 1 appears at the top of media upload interface 800, and image 2appears at the bottom of media upload interface 800, consumer 215 willfirst see image 1 for the length of time set in the media durationslider associated with image 1, and then consumer 215 may see image 2for the length of time set in the media duration slider associated withimage 2. Media upload user interface 800 may also include a previewoffer button that allows the vendor to preview the deal thereby allowingthe vendor to adjust the media, display duration of media, ortransitions between media as needed.

In some embodiments, the vendor may wish to geographically restrictwhere deals may be presented. FIG. 9 shows one embodiment of geographicrestriction user interface 900. Geographic restriction user interface900 advantageously allows a user to select regions where deals may run,or exclude regions where deals may not run. Geographic restrictioninterface 900 may permit more than one region of inclusion of exclusion.Geographic restriction user interface 900 may include map element 905.Map element 905 may, in some embodiments, be implemented using a wellknown mapping tool or API, such as, for example, Google Maps, FalconView, or any other readily available mapping tool that allows foroverlay of graphics. Map element 905 may provide for zoom tools andnavigation tools that allows a user to manipulate the map so that theymay view the location for where they would like to place a geographicrestriction. A user may, for example, select a region of the map with aselection tool and draw border 910 around a region of the map. Once theborder has been drawn on the map, the user may select whether the regionis to be inclusive or exclusive using radio buttons 920. For example, ifthe user would like the deal to run only within inside the selectedregion, then the user would select the “Inclusive” radio button.Geographic restriction interface 900, in some embodiments, may allow forthe user to create multiple regions for where deals should be displayed.For example, the user may define a large “inclusive” region, and thendefine a smaller “exclusive” region inside the large “inclusive” regionwhere the deal would not be offered, if the user (vendor) desired not topresent the deal in a particular neighborhood or business area.

In one embodiment, once the vendor has completed entering the dealinformation using the user interfaces of FIGS. 6-9, the deal informationmay be communicated by vendor system 310 to deal manager 300 where dealdefinition module 305 may process the deal definition and store it indata store 303. In some embodiments, deals may be updated. The vendormay access a saved deal through user interface similar to the onesillustrated in FIGS. 6-9. The user interface used for creating a newdeal definition may also be used for modifying a deal definition bypre-populating the user interfaces with a saved deal definitioninformation. Deal manager 300 may provide a list in the user interfacefor the vendor that allows the vendor to select from predefined deals,and may allow the vendor to modify those predefined deals. In someembodiments, vendor system 310 may execute an application for updating adeal definition. Vendor system 310 may be, for example, a mobilecomputing device with a mobile application. The mobile application mayprovide the ability to alter details of the deal, such as the price, thetime the deal should launch, or deal text. In some embodiments, apredefined deal may be launched on demand. For example, the user ofvendor system 310 may wish to launch a deal to stimulate business. FIG.10 shows one embodiment of user interface 1000 for launching a dealon-demand. User interface 1000 allows for the input of the number ofdeals available in text field 1010 and the price of the deal in textfield 1020. The user interface 1000 also provides launch button 103which will launch the deal “on-demand.” In another embodiment thefunctions of the vendor system 310 may advantageously be made a part ofthe deal manager 300 and the input from the vendor as well ascommunication with the vendor's in-house inventory management system maybe provided through the internet and a browser interface.

Returning to FIG. 5, at step 2, deal manager 300 publishes the deal.Deal manager 300 may publish the deal in response to a real-timeimmediate publication request (such as the one issued by theillustrative embodiment of FIG. 10, or it may publish a deal that wasdefined at an earlier time and stored in data store 303. Deal manager300 may publish deals by communicating deal information across network380. In one embodiment, deal manager 300 may publish deals in abroadcast paradigm, that is, deal manager 300 may publish deals withoutdirecting the deals to a particular target deal presenter 100, and it isup to deal presenter 100 to determine whether to display the deal. Inanother embodiment, deal manager 300 may maintain a list of registereddeal presenters and may direct deal publication to those deal presentersthat satisfy the deal definition. The processes for publishing anddisplaying deals is discussed further with respect to FIGS. 19 and 20.

Once deal presenter 100 receives the deal, it may display the deal ondisplay 103. FIG. 11 illustrates one embodiment of deal display 1100that may be displayed showing a promotional offer, or deal, that may beoffered to passenger 115 or consumer 215. Deal display 1100 may includedeal information 1101. Deal information 1101 may be information relatedto the deal including the deal name, the deal description, the dealcost, media for the deal (such as images and video), or any otherinformation that was part of the deal definition created by vendorsystem 310. For example, in the illustrative embodiment of FIG. 11, dealinformation 1101 includes an indication of how many other passengershave purchased the deal, an image displaying the deal, the number oftickets (deals) available, and the price of the deal. Deal display 1100may also include a series of graphical buttons 1102, 1103, and 1104 thatare configured to receive user input selections. For example, ifpassenger 115 wishes to purchase the deal, they may select button 1102.If passenger 115 is not interested in the current deal, but rather wouldlike to view other deals, passenger 115 may select button 1103, to seeall deals in a list form, or may select button 1104 to show thecategories of available deals.

In one embodiment, deal presenter 100 may provide a user interface thatallows passenger 115 to browse available deals. FIG. 12 shows oneembodiment of category interface 1200 that may be displayed on dealpresenter 100. Category interface 1200 may include category buttons1201. Once selected, category buttons 1201 may show the deals availablein a category in a list form (as shown in FIG. 13). Category buttons1201 advantageously act as a filter, that is, once selected, the dealsdisplayed may be limited to the selected category. For example, ifpassenger 115 selects the restaurants button, only those deals of therestaurants category (as defined in vendor registration user interface600, for example) may be displayed. Category interface 1200 may alsoinclude a show all deals button 1202. Show all deals button 1202 mayshow all deals in a list form without filtering the list by category.Category interface 1200 may also provide show deals button 1203 thatwill return user to deal display 1100, which advantageously displays onedeal at a time.

FIG. 13 illustrates one embodiment of deal list interface 1300. Deallist interface 1300 advantageously lists the available deals in listformat, thereby allowing passenger 115 to quickly browse the availabledeals that are currently available for purchase. In one embodiment, thedeals in the list are selectable, that is, a user may touch or selectthe deals in the list and the deal information may then be displayed ina user interface similar to the illustrative user interface illustratedin FIG. 11. The deals displayed in the list may be filtered by categoryor, in other embodiments, may be filtered based upon whether adult dealshave been enabled. Filtering may be canceled through the selection ofcancel button 1303. Deal list interface 1300 may also include adultentertainment enablement button 1303 that when selected may display theillustrative user interface of FIG. 14. FIG. 14 illustrates oneembodiment of a user interface for enabling display of adultentertainment related deals. The illustrative user interface of FIG. 14advantageously provides buttons for verifying that passenger 115 isolder than 18. Deal list interface 1300 may also comprise ShowCategories button 1304 that may return the user to category userinterface 1200 when pressed.

In one embodiment, once passenger 115, or consumer 215, selects purchasebutton 1102, deal presenter 100 may display payment information userinterface 1500. Payment information screen 1500 may contain, forexample, quantity selection buttons 1501, advantageously allowingPassenger 115 may select the number of tickets he would like to purchasein the deal. The quantity selection may affect payment summary 1502,that is, as the quantity is changed, the total in payment summary 1502may update. Payment information screen 1500 may also include paymentinstrument selector 1503, advantageously allowing for the selection of apayment instrument, such as, for example, a Visa card, a Master Card, anAmerican Express card or a Discover card. Payment information screen mayalso comprise credit card information entry user interface elements 1504for entry of credit card numbers and CVN codes. Once passenger 115 hasentered the appropriate data, passenger 115 may purchase the deal byselecting purchase button 1505. In some embodiments, purchase button1505 may be disabled, or grayed out, until the passenger 115 has enteredthe required data for payment processing. If, however, passenger 115does not wish to purchase the deal, they may exit payment informationscreen 1500 by pressing cancel button 1506.

Returning to FIG. 5, once passenger 115 indicates they would like topurchase a deal and enters the appropriate payment information, dealpresenter 100 communicates the deal acceptance and the paymentinformation to deal manager at step 3. The deal acceptance may alsoinclude location information indicating the location of passenger 115 orconsumer 215 when accepting the deal. In embodiments where passenger 115accepts the deal as a result of in-vehicle deal presentation, thelocation information may not be the absolute physical location ofpassenger 115, but rather, may be an identifier associated with the FHVin which passenger 115 is traveling. In embodiments where consumer 215has accepted the deal as a result of a FHV-top display presentation, orpersonal computing device presentation, the current location of consumer215 may be communicated to deal manager 300. The current location may bein the form of GPS coordinates obtained from the on-board GPS processorof the mobile device, for example

Once deal manager 300 receives the acceptance from deal presenter 100,deal manager 300 may attempt to process payment in step 4. Deal manager300 may extract from the acceptance data, payment information that waspart of the acceptance. For example, deal manager 300 may extract thepayment instrument type selected with payment instrument selector 1503and may also extract the credit card number and CVN code from theacceptance data. In some embodiments, this data may be encrypted usingan encryption algorithm known in the art. In such embodiments, dealmanager 300 may decrypt the payment information before packaging it tosend to payment processor 320. Payment processor 320 may expose an APIallowing payment information to be sent to it. Deal manager 300 andpayment processor 320 may communicate using commonly understood methodsof communication between computing systems.

Once payment processor 320 receives the payment information it mayprocess it and return the result of processing to deal manager 300 atstep 5. If the result of payment processing was successful, deal manager300 may generate a voucher, voucher number or serialized number(“voucher”) that may be used to redeem the deal at the vendor system310. The voucher advantageously represents a unique code or key that maybe used by passenger 115 or consumer 215 to redeem the deal at the venueof the vendor. The voucher may be a string of alpha-numeric characters,or in other embodiments, may be a UPC code or QR code that will bescanned at the venue. Deal manager 300 may store a record of the vouchercreation in data store 303. In embodiments where deals are limited by afixed inventory, deal manager 300 may also conduct inventory managementprocessing through the use of deal publishing module 306. Deal manager300 may, for example, decrement an inventory value associated with thedeal. For example, if a deal was defined as only having 10 ticketsavailable, the number of tickets available may be adjusted to 9, toindicate that one ticket has been purchased. Deal manager 300 may alsobroadcast a message to deal presenters indicating that for that deal thenumber of available tickets has decreased by one thereby allowing dealpresenters to update their deal displays.

Once payment has been verified, deal manager 300 may then determine, atstep 6, if there is a for-hire vehicle available for transportingconsumer 215 to the venue where the deal may be redeemed. Some deals,such as deals for shows or events, are time sensitive. As a result, dealmanager 300 may, in some embodiments, make a request of reservation anddispatch 350 to determine if the consumer's transportation request canbe fulfilled the estimated pick up time consumer 215. Once the estimatedpick-up time is received, deal manager 300 may then use the locationinformation of consumer 215 to estimate the time needed to travel to thevenue offering the deal. Using the estimated pick-up time, and theestimated travel time, deal manager 300 may then estimate the length oftime it would take for consumer 215 to get to the venue. Once the traveltime is determined, it is added to the current time to ensure thatconsumer 215 will arrive on time for her deal. In the event that a FHVcannot pick up consumer 215 in time for the show or event, deal manager300 may cancel the deal and refund the consumer's purchase of the deal.In some embodiments, the request to determine if consumer'stransportation request can be fulfilled is completed prior to paymentprocessing.

The flow of data then proceeds to step 7 where deal manager 300 thensends the voucher and purchase confirmation to deal presenter 100. FIG.16 shows one embodiment of deal confirmation user interface 1600. Dealconfirmation user interface 1600 advantageously includes voucher 1601.As shown in FIG. 16, voucher 1602 may be an alpha-numeric code, forexample “225-678”. In addition to providing the voucher on the displayof deal presenter 100, deal confirmation user interface 1600 may alsoinclude user interface elements that provide a means for passenger 115to input contact information so that the voucher may be sent directly tothe computing device of passenger 115. For example, deal confirmationuser interface 1600 may provide phone number text field 1602 for entryof a phone number corresponding to a mobile phone capable of receiving atext message. In addition, deal confirmation user interface 1600 mayalso provide email text field 1603 for entry of an email address.Passenger 115 may then a copy of the voucher, along with receiptinformation, to their personal computing device by selecting send button1604. In some embodiments, the deal confirmation may include anindication of where consumer 215 is to expect FHV 120 to pick them up totake them to the venue. For example, the deal confirmation may indicatea particular intersection, taxi stand or address where consumer 215should wait for the FHV to pick her up.

In some embodiments, deal manager 300 may generate a voucher coupon andsend it to deal presenter 100. The voucher coupon may be, for example,an image file containing the voucher number and a UPC or QR code. Thevoucher coupon may also contain information related to the event forwhich the deal is was purchased. For example, the event name may be onthe voucher coupon, and the deal amount may be on the voucher coupon. Insome embodiments, deal presenter 100 may have a printer connected to it.For example, if deal presenter 100 is an in-vehicle display, a thermalprinter may be connected to deal presenter 100 for printing the receivedvoucher image. In embodiments where deal presenter 100 may be a mobiledevice, an image may be displayed on the mobile device so that vendorsystem 310 may scan the UPC code or QR code for redemption. In someembodiments, deal manager 300 may send the generated coupon image in anemail to passenger 115 or consumer 215 to the email address entered inemail text field 1603.

Also in step 7, deal manager 300 may send to vendor system 310 aconfirmation message indication that deal has been purchased. Theconfirmation message may include identification information of passenger115 or consumer 215, if available. The vendor may then use theinformation of the confirmation message as a further check with thevalidation of the voucher as a means of further preventing fraud. Inaddition, the confirmation message may indicate, if appropriate, a seatnumber, position number, or other customer unique identifier to preventthe vendor from double selling a unique item. For example, suppose thevendor is providing a show with fixed seating. The vendor offers severalseats for sale, including seat 5A. Seat 5A is then sold in a dealpresented on deal presenter 100. The vendor receives confirmation thatSeat 5A was sold and as a result, will not then resell Seat 5A toanother customer who may walk up to the venue and wish to purchase aseat without a pre-purchased deal. To make sure that two seats are notsold to different customers at the same time the seats are held forshort time period (for example 5 to 10 minutes) when the customer hastaken the first step to accept the deal. Then if the seat is notpurchased within this time period the seat is released.

Moving to step 8, deal manager 300 advantageously sends a FHV request toreservation and dispatch 350 following the communication of the voucherto deal presenter 100 and the confirmation message to vendor system 310.The request may contain the location of consumer 215 and request an FHVto be dispatched to pick up consumer 215. For example, if consumer 215received a deal on their mobile device at Las Vegas Blvd and Fremont foran event at Las Vegas Blvd and Flamingo, the request may indicate thatthe passenger is to be picked up at Las Vegas and Fremont and thentransported to Las Vegas and Flamingo. The request may also indicatethat the fare for the trip has already be paid and will be credited tothe driver accepting the fare.

In some embodiments, deal presenter 100 may be an in-vehicle display andpassenger 115 may be traveling to a first destination when the deal isdisplayed and accepted. In this embodiment, the request message mayindicate that the request is not for a new dispatch, but rather to edita current trip sheet. The request may contain the location of passenger115 and request that the trip destination of passenger 115 be updated toreflect the location of the venue as the new destination. For example,if passenger 115 is traveling in a FHV to Las Vegas and Fremont when heaccepts a deal for an event at Las Vegas and Flamingo, deal manager 300may send a request to reservation and dispatch 350 that the trip takenby passenger 115 be altered so that the destination of Las Vegas andFremont be changed to Las Vegas and Flamingo.

Once reservation and dispatch 350 receives the request, it may then senda dispatch message to FHV 120 at step 9. The dispatch message may, insome embodiments, be a dispatch to initiate a new passenger fare. Inother embodiments, the dispatch message may be a message to update thetrip sheet for passenger 115. Once dispatched, the driver of FHV 120 maypick up the passenger and take them to the venue of the vendor.

Finally, at step 10, the voucher sent to passenger 115 or consumer 215may be validated. In some embodiments, vendor system 310 and FHV 120 mayhave a specialized reader device that may scan UPC or QR codes fromvoucher coupons. In other embodiments, the voucher code may be submittedby vendor system 310 or the driver of FHV 120 to deal manager 300through the use of web portal, mobile or IVR application. For example,FIG. 18 illustrates one embodiment voucher redemption interface 1800. Inone embodiment, a user may enter an alpha-numeric code into voucher codetext field 1801. Once entered, the user may submit the voucher code todeal manager 300 by pressing validate button 1802. In anotherembodiment, the voucher code may be validated through the use of an IVRapplication that interfaces with deal manager 300. A user may call aphone number associated with deal manager 300 and read the alpha-numericvoucher code. The IVR application advantageously interprets the vouchercode and sends the voucher code information to deal manager 300.

Once deal manager 300 receives the voucher code, deal manager 300 mayvalidate and redeem the deal. In one embodiment, deal publishing module306 may mark a row in data store 303 corresponding to the voucherindicating that is was redeemed and can no longer be redeemed if thevoucher code is valid. In some embodiments, vouchers may be redeemed bydrivers (as part of transportation fulfillment) and may also be redeemedby vendors. As a result, deal manager 300 may maintain separate datastructures for a voucher code indicating that it has been redeemed onceby the driver of FHV 120, and once by the vendor system 310. If thevoucher code is not valid, deal manager 300 may send a validation failedmessage back to vendor system 310 or the driver of FHV 120 indicatingthat the voucher is invalid.

FIG. 19 is a flow chart depicting the process flow of one embodiment ofa deal manager 300. At block 1901, deal manager 300 may receivepromotional offer data for a deal from a vendor system 310. Thepromotional offer data may include deal data as described above withrespect to FIGS. 6-10. For example, the promotional offer data mayinclude deal information describing the deal, time restrictions,location restrictions, the number available at that price (checked inreal time), a retail price, images, or other data that may define adeal. The deal information may, for example, contain a description ofthe deal being offered to the consumer. Time restrictions may indicatethe time a deal is to run. A time restriction may include a start time,such as 6 PM on Jul. 1, 2011 and an end time, such as 10 PM Jul. 1,2011. Location restrictions may comprise a plurality of GPS coordinateddefining a region where the deal should be presented (“inclusiverestrictions”), or defining a region where the deal should not bepresented (“exclusive restrictions”). The retail price may be anindication of the regular price of the item offered in the deal.

In response to the received promotional offer data, deal manager 300 maygenerate a promotion offer, or deal, at block 1902. The deal orpromotional offer may include some of the promotional offer data. Inaddition, the promotional offer may include a consumer category. Theconsumer category may describe the type of customer that may beinterested in purchasing the deal. For example, a consumer category maybe “affluent traveler”, “businessman”, “family”, “adult entertainment”,“frequent dinner.” Once the promotional offer is generated, deal manager300 may publish the deal according to methods described in the presentdisclosure. For example, deal manager 300 may publish the deal in abroadcast paradigm. Once the promotional offer publishes, deal manager300 may wait for one or more acceptances of the promotional offer.

At block 1904, deal manager 300 receives the acceptance of a deal. Oncethe acceptance is received, deal manager 300 extracts locationinformation and payment information from the acceptance. The locationinformation indicates the location of deal presenter 100 at the time ofacceptance. The payment information includes data related to the amountpaid and the account number of the payment instrument. Deal manager 300then, at block 1905, sends the payment information to payment processor320 for processing. Once the payment successfully processes, dealmanager 300 may generate a voucher and send it to deal presenter 100 atblock 1906. Finally, at block 1907, deal manager 300 may generate andsend a transportation request to reservation and dispatch 350 based onthe extracted location information.

FIG. 20 is a flow chart depicting the process flow for one embodiment ofa deal presenter 100. At block 2001, deal presenter 100 receives apromotional offer. Once received deal presenter 100 may add thepromotional offer, or deal, to a monitor queue. The monitor queue may bea list of received deals that are analyzed on a periodic basis todetermine if all the restrictions, such as time and location basedrestrictions for example, associated with the deal are satisfied. Insome embodiments, the received deal may be added immediately to themonitor queue before being analyzed, while in other embodiments, thedeal is analyzed to determine if it should displayed immediately oradded to the monitor queue. Once the deal is added to the monitor queue,deal presenter 100 may periodically analyze the deals in the monitorqueue to determine if they should be displayed. At block 2002, the dealpresenter 100 determines if it should display the offer.

FIG. 21 is a flow chart depicting the process flow for one embodiment ofa deal presenter 100 showing one illustrative example of a display offerdecision process. The process shown in FIG. 21 describes just oneprocess for determining whether to display a deal on deal presenter 100and it should be understood that other processes and methods may be usedto determine when deals should be displayed. For example, another methodof determining whether deals should be displayed may be for dealpresenter 100 to display all deals it receives. It should also beunderstood that in some embodiments, some steps of the process depictedin FIG. 21 may not be performed. For example, in some embodiments, dealsmay not be matched to passengers or consumers based on target attributesas described with respect to block 2107. In one embodiment, the processshown in FIG. 21 is advantageously performed by presentation module 105.

At block 2101, presentation module 105 determines if the timerestrictions match the current time. If the time restrictions match thecurrent time, then processing moves to block 2104. For example, a dealmay have a time based restriction that it is to run from 1 PM on April 4to 10 PM on April 5. Presentation module 105 may determine that thecurrent time is 1:01 PM on April 4. As a result, processing may move toblock 2104. If, however, the time restrictions do not match the currenttime, processing moves to block 2102, where the presentation module 105determines if the deal has expired and should be removed from themonitor queue. Using the above example, if the current time is 10:03 PMon April 5, the deal has expired. As a result, presentation module 105will remove the deal from the queue at block 2103. If, however, thecurrent time is earlier than the start time, for example, 12:30 PM onApril 4, the deal is returned to the monitor queue at block 2105 and isnot displayed. Another example is that the deal would be removed fromthe monitor queue if all the inventory (of seats for example) have beensold.

When the time restrictions are satisfied, processing moves to block 2104where presentation module 105 determines if the current location matchesthe deal location parameters. The determination may depend on thecurrent location of deal presenter 100. For example, suppose dealpresenter 100 receives a deal that is geographically restricted to areasnorth of Interstate 215. The deal would enter the monitor queue alongwith other received deals. When presentation module 105 examines thedeal from the queue, it will determine the current location of dealpresenter 100. Presentation module 105 may, for example, determine itslocation through the use of a GPS unit connected to deal presenter 100(in the case, for example, of an in-vehicle deal presenter) or it mayuse a GPS that is part of deal presenter 100 (in the case of a mobilephone application deal presenter or an in-vehicle deal presenter, forexample). If deal presentation module determines that deal presenter 100is in a FHV that is south of Interstate 215, presentation module 105 maynot display the deal, but instead leave the deal in the monitor queue tobe re examined later at block 2105. In some embodiments, presentationmodule 105 may store the deal in memory and then display the deal whendeal presenter 100 travels north of Interstate 215, and processing maycontinue to block 2107.

At block 2107, the presentation module 105 determines if the deal targetattributes match the attributes of the passenger or consumer viewing thedeal presenter 100. The deal target attributes may, in some embodiments,be a consumer category. The deal may contain a consumer category thatdescribed a target consumer to which the deal should be displayed. Thepresentation module 105 may also decide whether the current consumer orpassenger is of the same consumer category. In embodiments where dealpresenter 100 is installed in a FHV, presentation module 105 maydetermine the passenger's consumer category based on information relatedto the passenger's trip. For example, if the FHV is a limo, as opposedto a shuttle or taxi, presentation module 105 may determine that thepassenger is of the consumer class “affluent traveler” or if the FHV isa mini-van, as opposed to sedan, the presentation module 105 maydetermine the passenger is of the consumer class “family.” Presentationmodule 105 may also use the pick-up location, or current destinationlocation, to glean information about the passenger that may be used todetermine the consumer class for the passenger. For example, if thepassenger is picked up at a high end hotel and is planning on travelingto a sushi restaurant, presentation module 105 may determine that thepassenger is of the “affluent traveler” and “frequent diner” consumercategories. In embodiments where deal presenter 100 is a mobile deviceor other general purpose computing system, a consumer category may bedetermined from the consumer's prior deal purchase history, or consumerentered attributes. In some embodiments, instead of or in addition toconsumer categories, destination information may be used to match dealswith a passenger. For example, if the passenger is traveling to an adultentertainment venue, presentation module 105 may match the passengerwith deals for other adult entertainment venues in the hope of thepassenger changing his or her desired destination.

Once presentation module 105 determines that the deal target attributesmatch the passenger or consumer attributes, processing continues toblock 2108. At block 2108, the total cost of the deal is determined. Insome embodiments, deal presenter 100 may not present a deal if the dealdoes not provide a discount once the current accumulated fare isincluded in the deal. Accordingly, presentation module 105 sums thecurrent accumulated fare and the deal rate at block 2108 after whichprocessing moves to block 2109 to determine if the summed value is lessthan the retail price of the deal. For example, deal presenter 100 mayreceive a deal for $20 tickets for $10. If, however, passenger 115 hasaccumulated a fare of $12, the accumulated fare, plus the cost of thedeal of $10 may result in a cost of $22 to accept the deal. Thus,presentation module 105 may not display the deal because the cost ofaccepting the deal for the ticket exceeds what the ticket would normallycost and the deal is returned to the monitor queue at block 2105. If,however, presentation module 105 determines that the accumulated fareplus the deal rate results in a deal price that is lower than the retailprice, processing may move to block 2010, and the deal may be displayed.In another embodiment the functions of the presentation module 105 ofthe deal presenter may advantageously be handled as part of the dealmanager 300. In this embodiment the deal manager would keep track of allthe current information about the for-hire-vehicles in the overallsystem including for example location and fare status as well as whatever information is known about the passenger(s). This information wouldthen be used to make the decision about where and when to present theoffers available.

Returning to FIG. 20, if deal presenter 100 decides to display thepromotional offer, it may then determine if the promotional offer hasbeen accepted at block 2003. If the offer is accepted, paymentinformation is collected at block 2004. The payment information may becollected, in some embodiments, through the use of a POS terminal. Oncethe payment information has been received, deal presenter 100 may sendthe acceptance to deal manager 300. Finally, at block 2006, dealpresenter 100 may receive confirmation that the promotional offer hasbeen processed and deal presenter 100 may receive a voucher that can beredeemed at venue 310.

FIG. 22 illustrates an embodiment of a deal manager computing system2200 in data communication with a promoter entity 2220, over a computernetwork (for example, the Internet). In certain embodiments, the dealmanager 2210 and/or promoter entity 2220 comprise one or more computerprocessors for processing data. The promoter entity may be anindividual, such as a driver of an FHV, a business, company, or otherentity. The promoter entity 2220 is associated with a promotionscommunication device 2222 that is outfitted with a deal serviceapplication 2223. The deal service application 2223 may be electronic,such as a downloaded software application, or may be physical, such asan advertising poster, leaflet, sticker, etc. Example electronic dealservice applications may include software applications, such as for useon a computer or smart phone. In the case of a physical application, theapplication may be a print advertisement, or the like. For example, theapplication may be a poster or billboard that serves to promote one ormore deals, wherein the poster or billboard displays an identifier, orcode, uniquely associated with the promoter entity 220. A consumer maypurchase a deal, or conduct a transaction promoted by the printmaterial, in response to viewing the material. In certain embodiments,the identifier displayed may be input in connection with such a purchaseor transaction, thereby providing information to the deal manager 2200which is used by the promotion compensation module 2212 in calculating abenefit to provide to the promoter entity 2220 as compensation forpromoting the deal or service. The deal service application 2223 maypromote one or more specific deals provided by a deal service, or thedeal services generally.

In one embodiment, deal manager 2200, is a computing system that is IBM,Macintosh or Linux/Unix compatible. Deal manager 2200 may, in someembodiments, include one or more processors, which may include one ormore conventional or proprietary microprocessors. Deal manager 2200 mayfurther include memory, such as random access memory (“RAM”) fortemporary storage of information and/or read only memory (“ROM”) forpermanent storage of information, and/or other data storage, such as ahard drive, diskette, or optical media storage device. In certainembodiments, the deal manager includes data storage needed for managingand maintaining deals, or for storing historical deal information. Suchstorage may store data in databases, flat files, spreadsheets, or anyother data structure known in the art.

The deal manager 2210 may be generally controlled and coordinated byoperating system software, such as the Windows 95, 98, NT, 2000, XP,Vista, Linux, SunOS, Solaris, PalmOS, Blackberry OS, iPhone OS, GoogleAndroid, or other compatible operating systems. In Macintosh systems,the operating system may be any available operating system, such as MACOS X. In another embodiment, deal manager may be controlled by aproprietary operating system, that is, one that had been custom made forthe purposes of embodying certain of the systems and methods describedherein. Conventional operating systems control and schedule computerprocesses for execution, perform memory management, provide file systemarchitecture, networking, and I/O services, and may provide a userinterface, such as a graphical user interface (“GUI”) for display, amongother things.

The deal manager 2210 may also include one or more commonly availableI/O devices, such as for example, a printer, buttons, a keyboard, adisplay, a touchpad, a USB port, and the like. In certain embodiments,the deal manager 2210 includes I/O devices and/or interfaces thatprovide a communication interface to various external devices. Forexample, the deal manager 2210 may be in communication with a computernetwork, such as any combination of one or more LANs, WANs, or theInternet, for example, via a wired, wireless, or combination of wiredand wireless, connections via a network interface of I/O devices and/orinterfaces. The deal manager 2210 may also include several applicationmodules that may be executed by one or more processors. Software codeassociated with one or more modules included in the deal manager 2210may be stored on a tangible computer-readable medium such as forexample, RAM or ROM.

The modules represented as promoter entity 2220, promotionscommunication portal/device 2222, and deal service application 2223 maycomprise many forms or attributes, as suitable or desirable. Forexample, in an embodiment, the promoter entity is an individual orcompany associated with an FHV, the FHV including a promotions computerdisplay, or other promotional tool. In an embodiment comprising acomputer display (such as the deal presenter described above), thecomputer display may prompt or allow access to a passenger of the FHV toview or interact with deal services, such as by using a downloaded,installed, or firmware-based deal services application.

In certain embodiments, the promoter entity is an individual or businessentity that controls or operates a billboard that displays deal servicecontent. The display may include an identifier, or code, associated withthe promoter entity, that may be input to the deal manager 2210 inconnection with a purchase or transaction made by a consumer. Theidentifier may be used by the promotion compensation module 2212 incalculating a benefit to provide to the promoter entity in compensationfor promoting the deal service content. In another embodiment, thepromoter entity is a commercial or residential building, such as anapartment building, hotel, office building, etc., including an elevator,or other conveyance device, such as an escalator, associated with adisplay screen, print media, or the like that displays deal servicecontent. For example, the deal service content may be in the form of aninteractive, or non-interactive, application on a display screen, suchas a display screen of a computer device connected to the display screeneither locally, or over a network. In another embodiment, the promoterentity 2220 is a retail or wholesale establishment, such as a grocerystore or department store, associated with an advertisement module(meaning, promotions communication portal) that displays deal servicecontent (meaning, deal service application). For example, theadvertisement module may be associated with a self-checkout display, orother in-store module (such as the displays often seen at cash registerswith displays, which may advantageously be interactive, permitting touchscreen entry by the user). In certain embodiments, as an individual isengaged in a checkout transaction, a device prompts or allows theindividual to access or view a deal service application contained on orwithin the device, such as by selecting an icon on a screen. In someembodiments, the promoter entity is an individual or business entityassociated with a billboard (meaning, promotions communication portal)that displays deal service content (meaning, deal service application).The embodiments described above are intended as examples only, and thepromoter entity 2220, promotions communication portal/device 2222 anddeal service application 2223 may take on any suitable or desirableform, or may be used in any suitable or desirable context.

The promotions communication portal/device 2222 and/or deal serviceapplication 2223 may include functionality or promote functionalityallowing for data related to a consumer's attention to or solicitationof deals or services promoted by the promotions communication device tobe transferred to a deal manager system 2210. Such transfer may befacilitated, for example, by entering a promotional code by a consumeror the promoter entity 2220, such as a code that identifies a particularpromoter entity 2220, either locally, or at a remote location. Incertain embodiments, transfer of transactional data is facilitated byconnecting the promotions communication portal 22 to the deal managersystem 2210, such as over a network.

In certain embodiments, the deal manager system comprises one or morecomputer servers, processors, I/O devices, or other computingfunctionality. The promotions communication portal and/or deal serviceapplication may provide the transaction data to the deal manager system2210 over a network, such as the Internet, or a telephone network, orthrough some other transmission medium, whether electronic or physical,such as the postal service. The deal manager system 2210 may beconfigured such that transactional data from the promotionscommunication portal 2222 is stored in a transaction data database 2214.Transaction data may include, for example, date and/or time informationassociated with a deal service transaction.

The deal manager system 2210 includes a promotion compensation module2212. The promotion compensation module 2212 may include one or moreprocessors and/or memory devices, and may be in data communication withthe transaction data database 2214. In certain embodiments, thepromotion compensation module 2212 includes data associated with paymentpreferences or methods associated with one or more promoter entities.Payment preferences or methods may include, for example, designation ofa bank account for direct-deposit, or payment by check or cash, or othermethod of payment.

In certain embodiments, the deal manager 2210 and/or transaction datamodule 2214 include data that allows for distinguishing betweendifferent promoter entity types. For example, the deal manager 2210 mayinclude functionality to distinguish between taxi drivers, limo drivers,and/or other FHV drivers. In certain embodiments, the deal manager 2210includes functionality to distinguish between drivers in a certaingeographic area, or drivers in service a certain time. Suchfunctionality may advantageously allow for communication or interactionwith selective groups of promoters.

The promotion compensation module 2212 facilitates the transfer ofcompensation or other benefit to the promoter entity 2220, or to anaccount or entity associated with, or designated by, the promoterentity. Example types of benefits may include money payments, “in-kind”transfers, or a voucher, or other type of benefit or combination ofbenefits) For example, the promotion compensation module may transfercompensation to the promoter entity automatically or otherwise based ontransactional information received from the promotions communicationportal 2222. Compensation may include any combination of money,vouchers, awards, recognition, or any other form of consideration orcompensation. In certain embodiments, when a consumer conducts atransaction in connection with, or based on, the promotionscommunication portal 2222, the promotion compensation module 2212receives data associated with such transaction from the transaction datadatabase 2214, and, based at least partly on such transaction,transfers, or causes the transfer of, compensation to the promoterentity 2220. In certain embodiments, compensation is transferred bymail, such as in the form of a check.

FIG. 23 is a block diagram illustrative of an embodiment of a dealmanager computer system 2310, which may comprise one or more computingsystems controlling its operation, in communication over network 2360with an employer entity 2340 and/or one or more venues 30, amongpossibly other entities or devices, as illustrated. While FIG. 23 mayillustrate various components of the system 2300 as separate computingsystems or modules, the functionality provided for in the systems andmodules of FIG. 23 may be combined into fewer components and modules orfurther separated into additional components and modules. In addition,while the blocks of FIG. 23 are described in the singular for ease ofreference, embodiments may include more than one of any of the variousblocks. For example, in one embodiment, there will advantageously be aplurality of venues/vendors 2330, employer entities 2340, consumers2350, and/or promoters 2320, 2322, and/or a plurality of FHV's 2326,2328. The various components of the system 2300 may be related orconnected, such as through ownership, social or business interaction,employment, or otherwise. As illustrated in the figure, solid linesindicate data communication between two or more components, while dashedlines represent some type of association or relationship betweencomponents that does not necessarily correspond to a data communicationlink between them.

In an embodiment, the deal manager 2310 is a computing systemresponsible for managing deals. The deal manager 2310 may advantageouslyprovide interfaces for vendors to define deals and may accept dealdefinitions created by vendors. The deal manager 2310 may also assist inthe publication of deals to one or more promoters 2320, 2322. The dealmanager 2310 may also receive information relating to the acceptance ofa deal, for example by a consumer 2350. In certain embodiments, whendeal manager 10 receives information from a promoter, for example,promoter A 2320, that a deal service transaction has taken place, thedeal manager 2310 may facilitate the transfer of compensation to thepromoter and/or an employer entity associated with the promoter based atleast in part on the transaction information. For example, a promotermay receive compensation a per-transaction basis.

The system 2300 includes one or more promoters (for example, promoter Aand promoter B) engaged in promotional activities related to dealservices provided through the deal manager 2310. As described herein,promoters may be individuals, businesses, or any other type of entity.Once a promoter has registered with the deal manager 2310, such asthrough an online registration process (see FIG. 26), or any othersuitable registration process, certain information relating to thepromoter is contained within the promoter database 2312. Suchinformation may include, for example, information relating to method oftransferring compensation to the promoter, such as bank accountinformation, physical address, and/or the like. Examples of types ofpromoters may include taxi drivers, venue doormen, concierges, or otherservice providers. The promoter 2320 may also provide feedbackinformation to the deal manager system 2310, such as information relatedto vendors, or experiences or comments related to the deal manager'sdeal services.

In certain embodiments, a promoter can promote deal services providedthrough the deal manager 2310 to one or more consumers 2350. Forexample, a promoter may be a driver of an FHV, and a consumer 2350 maybe a passenger of the FHV 60. In certain embodiments, the promoter 2320promotes deal services to the consumer 2350, for example, while theconsumer 2350 is a passenger in an FHV 26 driven by the promoter 2320.When the promoter 2320 is successful in promoting deal services, thatis, the consumer 2350 engages in a transaction in connection withpromotional efforts of the promoter 2320, then the promoter and/or thepromoter's employer or affiliated company, may receive compensation fromthe deal manager 2310. A transaction may be connected to a promoter'spromotional efforts if, for example, the consumer 2350 inputs a codeuniquely identifiable with the promoter 2320 when making thetransaction. Other information may also demonstrate a connection betweenthe promoter's efforts and a transaction, such as a network address of adevice used in the transaction, a time-stamp of the transaction, alocation of the transaction, or other information. Certain embodimentsprovide a system 2300 that permits access by vendors to people such taxidrivers, limo drivers, doormen, and/or others that providerecommendations for venues such as shows, clubs and restaurants.

In certain embodiments, the consumer 2350 may download a deal serviceapplication from the deal manager 2310 to an electronic device 2352,which may be a mobile device. Such a download may be considered atransaction for purposes of prompting compensation of the promoter 2320.In certain embodiments, downloading of the deal service application maybe done in connection with entering a code or other identifierassociated with the promoter, thereby linking the consumer 2350 to thepromoter 2320. In certain embodiments, future transactions using thedownloaded application may also prompt compensation of the promoter 2320and/or an employer 2340. For example, employer 2340 may be a companyowning or leasing one or more FHV's. Compensation of the promoter 2320in connection with use of the downloaded application may continueindefinitely, or for a certain period of time. For example, the promoter2320 may be able to receive compensation in connection with use of thedownloaded application, or for transactions associated with thepromoter's identifier, while the promoter's registration information iscurrent or valid with respect to the promoter database 2312. In certainembodiments, when promoter 2320 switches company/employer or geographicaffiliation, the promoter's registration information may become invalid,and further transactions will not result in any compensation being paidto the promoter.

The system 2300 may be configured such that the promoter 2320 isnotified, for example, via text message, email, or other mechanism, whenthe consumer 2350 conducts a transaction using the downloadedapplication or in connection with the promoter's identifier. Suchnotification may provide incentive or encouragement for the promoter toengage in continued promotional activities. As described in greaterdetail above in connection with FIG. 4, for example, consumertransactions using the downloaded application may involve the consumertransmitting a deal request/acceptance to the deal manager 2310 over anetwork 2360 and receiving a deal voucher, either electronically orotherwise, in response from the deal manager 2310.

In addition to, or in alternative to, promoting the downloading of dealservice applications, the promoter 2320 may be compensated for variousother promotional efforts. For example, the promoter 2320 may be thedriver of an FHV 26 that contains a promotions communicationportal/device, as described above in connection with FIG. 22. In certainembodiments, FHV 26 contains a computer device including a displayvisible to passengers of the FHV, as described above with respect toFIG. 1. The consumer 2350 may advantageously conduct a deal transactionusing the computer device in the vehicle. In certain embodiments, such atransaction may be linked with the promoter 2320, such that thepromotion compensation module 2312 is configured to calculate thebenefit or amount due to the promoter 2320 based on the transaction. Forexample, the deal manager 2310 may include information related toFHV/driver association, such as driving schedules, vehicle identifiers,or any suitable means of identifying the promoter 2320 as the driver ofthe FHV 2326 at the time of a transaction. In an embodiment, theconsumer inputs the promoter's identifier into the computer device atthe time of the transaction. This may advantageously be done by taking ascan or photo of a bar code or QR code, for example, which is in thevehicle, or on a card. In certain embodiments, a distribution cardprovided by the driver includes a magnetic strip that may be scannedusing a card reading device, the magnetic strip containing the driver'sidentifier. In another embodiment, the drivers identification code isautomatically included based on the driver's identification input by thedriver when the driver begins his shift.

The system 2300 may include one or more additional promoters and/orFHV's (for example, promoter B 22, FHV 28), which may or may not beassociated with promoter A, FHV 26, and/or promoter A's employer.Promoter database 2314 may include registration information related toboth promoter A and promoter B and may advantageously includefunctionality to compare performance, such as the number of associatedtransactions, between a large number of promoters stored in the promoterdatabase 2312. In certain embodiments, the promoter database 2314 mayinclude functionality to sort promoter performance by venue. Forexample, promoter database 2312 may include functionality to provide alist of top performers with respect to deals offered by a specificvendor. Such information may be of interest to the venue for promotionalreasons.

As described above, deal manager 2310 includes a promoter database 2312that includes various information related to one or more promoters, suchas promoters who are registered with the deal manager 2310 asparticipating promoters. The system 2300 may provide a means for apromoter to register with the deal manager 2310 in order to facilitatereceiving compensation from deal manager 2310 for promotionalactivities, among other things. The promoter database may include suchinformation as registration information (described in greater detailbelow with reference to FIG. 26) and transaction data associated withdeal transactions facilitated or promoted by one or more promoters. Thetransaction data may include, for example, information relating to thenumber of transactions a given promoter or promoters are involved with,or associated with. This information may facilitate identification ofpromoters who are relatively successful in their promotional activities(for example, a “top performers” subset of the total set of registeredpromoters), for purposes of, for example, performance evaluation.Performance evaluation may be based on a number of types of information.For example, performance evaluation may be based on the quantity orquality of transactions, location of transactions, type of dealsinvolved in the transactions, time of day during which transactions areconducted, or other information. In an embodiment, performance ismeasured by, for example, the number of transactions or purchases agiven promoter was responsible for over a given period of time, such asa week or month. For example, a top performers group may include allpromoters who were the source of at least ten purchases/downloads in aweek. In another embodiment, a top performers group may include apercentage of registered promoters with the highest volume ofpurchases/downloads. For example, the top performers group may includethe top 10% or 20% of promoters, or some other percentage.

The system 2300 may be configured such that transaction data stored bythe deal manager 2310 may be provided to one or more entities, such as,for example, a vendor 2330, or an employer or potential employer 2340.For example, the deal manager 2310 may provide transaction data to venue2330, possibly in response to a data request. The venue 2330 may providepromotional materials or secondary incentives to the deal manager 2310based on the data, for example, to be conveyed to a subset of thepromoters (taxi and limo drivers, for example) who have been especiallyhelpful in receiving a relatively large number of purchases by thevenue. Secondary incentives may include some type of compensation, suchas a voucher for use in connection with the venue 2330, or some type ofaward or recognition. In an embodiment, the data received by the venue2330 does not contain personal identification information relating topromoters. For example, the data may merely comprise general notice ofpromotional activity of registered promoters, such as informationrelated to top performers among the registered promoters. In certainembodiments, the deal manager 2310 stores information relating to one ormore vendors, the deal manager 2310 including functionality to separateinformation relating to promoters and information relating to vendors.

The system 2300 may advantageously allow for indirect communicationbetween vendors 2330 and promoters 2320, 2322, while maintainingcomplete confidentiality of the promoters. In certain embodiments, thesystem 2300 does not provide a mechanism by which vendors can reach outto promoters directly or discover names, addresses, or other personalinformation of promoters.

Likewise, the employer (such as a taxi fleet operator) may receivetransaction data, for example, through a network 2360, either on aperiodic basis or in response to a request or other event. For example,an employer may wish to convey employment materials to one or morepromoters by transferring such material to the deal manager 2310, andthe deal manager 2310 transferring the material to one or moreregistered promoters. In certain embodiments, the registrationinformation contained in the promoter database provides information foruse by the deal manager 2310 in contacting registered promoters. Thevendor may send materials, via the deal manager 2310, to specificsubsets of promoters. For example, a vendor may wish to send materialsto promoters (as opposed to sending material only to deal presenters inparticular FHVs) that fit specific criteria, such as being in aparticular place at a particular time, or the like. Such information maybe available in promoter database 2314.

In certain embodiments, the deal manager 2310 transfers informationusing a mass-communication mechanism, such as a blast email or textmessage, to all or a selected subset of the registered promoters. Forexample, the deal manager 2310 may use a mass-communication mechanism toconvey information or material to promoters that was provided by a venue2330 or employer entity 2340. The subset could be drivers who will beworking on a particular night, drivers working in a particularterritory, or drivers available at a particular time.

FIG. 24 illustrates a flow chart for a method 2400 for promoting a dealusing information related to a promoter and compensating the promoterfor promotional efforts. At block 2410, a deal manager system receivespromoter registration information (for example, using the promoter-userinterface of FIG. 26). In certain embodiments, the registrationinformation is input using a user interface of a computer system by anindividual, such as an FHV driver, who is interested in promoting dealsand being compensated therefore. Upon receipt of the promoterregistration information, the deal manager system generates a promoteridentifier associated with the promoter. This takes place at block 2430.For example, the identifier may be a unique identifier associated withthe promoter and may include one or more alpha-numeric characters. Incertain embodiments, the identifier is a five-digit number. In certainembodiments, registration information is received in hard-copy form andprocessed by a processor system in the deal manager system.

Once the promoter identifier has been generated, it is provided,electronically or otherwise, to the promoter. This step is performed atblock 2430. For example, the promoter identifier may be provided viaemail or text message, or may be printed on physical business cardswhich are provided to the promoter (see FIG. 28). Such cards may bedesigned to be distributed by the promoter in order to promote one ormore deals, a deal service, and/or the promoter identifier of thepromoter to potential consumers. Furthermore, cards may have a barcode,a QR code, and/or magnetic strip to permit easy transfer of the code.

At block 2440, the data manager system receives a request from acustomer to download a mobile application associated with a dealprogram. In certain embodiments, the deal manager system is configuredto receive along with the request a promoter code input. For example, acustomer may enter the promoter code in connection with the downloadrequest. In an embodiment, a promoter code field is automaticallypopulated based on driver schedule information, or other informationindicating the identity of the promoter driver (such as the driver'slogin at the start of his shift). For example, an electronic device ofthe driver may communicate wirelessly with a point-of-sale device orapplication to identify the driver. Upon receiving the request, acontroller of the deal manager system facilitates the download of themobile application from the deal manager system to a customer deviceover a network.

Based on the promoter code included with the download request, the dealmanager system determines a fee or other compensation (such as freetickets or vouchers) to be paid to the promoter associated with thepromoter code, and provides the fee payment to the promoter through somemeans. In certain embodiments, the promoter registration informationprovides payment preference information upon which the payment transferis based. For example, the deal manager system may wire or otherwisetransfer a money payment to an account identified by the promoter, orpayment may be transferred to the promoter's employer, who may furtherdirect the payment, or a portion thereof, to the promoter through theemployee pay check. The fee payment may serve as compensation forpromotion by the promoter of one or more deals or services to thecustomer.

FIG. 25 is a flow chart depicting the process flow of an embodiment of aprocess 2500 of processing a deal and compensating a promoter therefore.At block 2510, a deal manager may receive promotional offer data for adeal from a vendor system. The promotional offer data may include dealdata as described above with respect to FIGS. 6-8 2510. For example, thepromotional offer data may include deal information describing the deal,time restrictions, location restrictions, the number available at thatprice (checked in real time), a retail price, images, or other data thatmay define a deal. The deal information may, for example, contain adescription of the deal being offered to the consumer. Time restrictionsmay indicate the time a deal is to run. A time restriction may include astart time, such as 6 PM on Jul. 1, 2012 and an end time, such as 10 PMJul. 1, 2012. Location restrictions may comprise a plurality of GPScoordinates defining a region where the deal should be presented(“inclusive restrictions”), or defining a region where the deal shouldnot be presented (“exclusive restrictions”). The retail price may be anindication of the regular price of the item offered in the deal.

In response to the received promotional offer data, the deal manager maygenerate a promotion offer, or deal, at block 2520. The deal orpromotional offer may include some of the promotional offer data. Incertain embodiments, the deal manager may provide access to consumers toexclusive deals unavailable with other deal sources. In addition, thepromotional offer may include a consumer category. The consumer categorymay describe the type of customer that may be interested in purchasingthe deal. For example, a consumer category may be “affluent traveler,”“businessman,” “family,” “adult entertainment,” “frequent diner.” Uponreceiving the promotional offer data, the deal manager system may beconfigured to query the vendor, or a local database, to determinewhether the promotional offer is the best currently available offeroffered by the vendor. For example, the deal manager may providenotification to the vendor if it is determined that the deal is not thebest current offer available to advertise, and may encourage the vendorto provide an alternative deal. Once the promotional offer publishes,such as on an in-vehicle deal presenter, as described above with respectto FIG. 1, among others, the deal manager may wait for one or moreacceptances of the promotional offer.

At block 2550, the deal manager receives an acceptance of a deal in theform of a solicitation from a consumer. The solicitation may includeinformation associating the solicitation with a specific promoteridentifier. At block 2560, the deal manager processes paymentinformation of the consumer and generates and sends a voucher to theconsumer related to the deal at block 2570. Transmission of the vouchermay be contingent on successful processing of the payment information.The payment information may include data related to the amount paid andthe account number of the payment instrument.

At block 2580, the deal manager calculates a benefit to be provided tothe promoter. In certain embodiments, the compensation is of the form ofa money payment, such as, for example, a small percentage(advantageously between 0.01% and 2%) or a flat payment in an amountbetween $0.01-0.49, $0.50-0.99, $1.00-5.00, or higher. The calculatedvalue may diminish as the time since the consumer was contactedincreases, such that over the course of a year, the value may be, forexample, reduced to zero. In certain embodiments, recurrent contact withthe consumer increases the benefit value, or prevents the benefit valuefrom decreasing.

FIG. 26 is a screenshot showing an embodiment of a promoter-registrationuser interface. The user interface of FIG. 26 may advantageously be aweb page or user interface of a computer application that executes on asystem that may be in communication with a deal manager system.

In some embodiments, a promoter may register with a deal manager.Registration may facilitate compensation of a promoter for promotionalservices provided. Various types of information related to the promotermay be required, or desired, in association with registration of thepromoter. Examples, as shown, include name, physical address, emailaddress, phone number, gender, date of birth, employer, login password.After registering, a promoter may be able to login to a server managedby the deal manager to perform various tasks, enter or revise or updatepreviously submitted information, or view content provided on theserver. For example, server content may include promotional materialrelated to promoter compensation and/or various deals and promotionsdirected to all promoters or to particular categories of promoters, suchas drivers, or to subcategories of drivers, for example, all driversthat are currently located in a particular geographical area.

In some embodiments, the data entered into the user interface by thepromoter may be used by the deal manager system to generate one or moreidentifiers associated with the promoter. The term “identifier,” is usedherein according to its broad and ordinary meaning and may include, forexample, a unique code comprising one or more alphanumeric characters.

FIG. 27 illustrates an embodiment of a portable promoter registrationsystem 2700 in accordance with one or more embodiments of the presentdisclosure. The registration system 2700 includes a deal manager system2710 including a promoter database 2714. In certain embodiments, apromoter 2720 can register with the deal manager system 2710. Promoter2720 may be, for example, an employee of employer A 2740 at the time ofregistration with the deal manager system 2710. Employer A may be aparticipating company and have a relationship or affiliation of somekind with the deal manager system 2710.

At some point, promoter 2720 may leave the employ of employer A. Forexample, promoter 2720 may leave employer A and become employed byemployer B (illustrated by line 2702). In certain embodiments, thepromoter's registration is portable in the sense that, in certaincircumstances, the promoter 2720 can maintain its registration andrelationship with the deal manager system 2710 when changing employmentpositions. That is, it is not necessary for the promoter 2720 tore-register with the deal manager system 2710. In certain embodiments,in order for the promoter's registration to be maintained through achange of employment, employer B must also have a relationship with thedeal manager 2710, for example, as a participating company or entity. Incertain embodiments, as long as employer B is a current/active owner oroperator in the deal service program and maintains deal presenterdevices in at least some FHV's owned by the employer.

The promoter 2720 may leave employer A and work independently of anemployer (as illustrated by arrow 2704), or work for an employer thatdoes not have a relationship with the deal manager 2710. In certainembodiments, the promoter 2720 may still be able to maintain itsregistration. Furthermore, in certain embodiments, the promoter 2720 mayrelocate to a geographic region that is outside the scope of thepromoter's employer's relationship with the deal manager 2710. However,the promoter 2720, depending on the embodiment, may still maintain itsregistration with the deal manager 2710 and exploit the deal manager'sassociated compensation program as a revenue stream. In this sense, theportability aspect of certain embodiments effectively allows a promoterto maintain a side-business comprising its promotional activities andincome associated with its status as a registered promoter and presencein the promoter database 2714. When the promoter changes employment fromemployer A 2740 to employer B 2745 (illustrated by arrow 2702), thepromoter's registration information contained in the promoter databasemay be updated by the deal manager 2710 to remove or modify informationrelating to the association between the promoter 2720 and employer A.Furthermore, the promoter's registration information may be updated toreflect an association between the promoter 2820 and employer B 2745. Incertain embodiments, other registration information is unaltered by thechange in employment.

FIG. 28 is an embodiment of a promoter identifier communication tool2800. In certain embodiments, the communication tool is a physical orelectronic copy of a business card that may be distributed in variousways, such as by personally handing to a potential consumer. Forexample, business cards may include a magnetic strip or RFID technologyfor communicating a promoter identifier. A deal manager may provide suchmaterials to a promoter in order to facilitate the promotionalactivities of the promoter. In the depicted embodiment, the card 2800includes the promoter's name 2802, title 2803, email address 2804, phonenumber 2805, and promoter identifier 2801. Furthermore, the card 2800may comprise a web address 2806 for a website or webpage associated withthe promoter. The website may be, for example, accessible only tocustomer's of that promoter and included as a private portion of theoverall content maintained by the deal manager. Furthermore, the websitemay provide a mechanism for the promoter to receive benefits incompensation for promoting deal services. For example, the webpage mayinclude advertisements for viewing by the promoter's customers. Thepromoter may receive compensation in connection with advertisement viewson his or her webpage. The webpage may include information, such asrecommendations, or may provide an interface for exchanging information,such as direct communication functionality, or concierge-type questions.In certain embodiments, the card 2800 includes one or more additionalpieces of information, or omits one or more of the pieces of informationdepicted in FIG. 28.

Distribution of a card or the like may provide a mechanism for apromoter to communicate its identifier to a consumer. However, anysuitable means for communicating the identifier may be implemented. Forexample, a promoter may transmit the identifier via some wirelessconnection protocol or media, such as BlueTooth, WiFi, RFID, infrared,inductive coupling, or the like. Such transmission may be from a card,phone, or may be from an intelligent system component that is able toidentify that the promoter is operating the FHV. Text messages and/oremails, which may contain a website link, may also provide a means tocommunicate the identifier.

FIG. 29 illustrates an embodiment of an electronic device utilizing adeal service downloadable application. The device 2900 includes adisplay for providing a visual interface for a user. The electronicdevice 2900 may be a handheld mobile device, such as a smart phone (forexample, an iPhone or Android phone), or any other type of electronicdevice comprising a display and having the ability to communicateelectronically with the World-Wide-Web. In certain embodiments, when auser, such as a consumer, downloads the deal service application to hisor her electronic device, an interface is presented to the user. Theinterface may serve as a means to allow a user to input a promoteridentifier and transmit the same to a deal manager system over anetwork. The promoter identifier, for example, may be associated with apromoter who directed or suggested the customer to download theapplication. Such download may occur at any location, such as in thepassenger compartment of an FHV over a wireless network. In certainembodiments, the promoter code field 2903 is automatically populated.Furthermore, in certain embodiments, the application/smartphone 2900allows for input of promoter identification through the use of a cameraimage capture of an identification number or symbol

The application may present the interface shown in FIG. 29 when theapplication is initially launched, and not necessarily thereafter. Incertain embodiments, it may be optional to enter some or all of theinformation requested on the interface shown. For example, it may bepossible for a user to enter the application by pressing a button 2904or otherwise without entering certain requested information. In certainembodiments, only the email address 2902 is required to be input by theuser before the user may proceed by pressing, or clicking the button2904, which causes the application to proceed past the interface shownin FIG. 29. In some embodiments, when the user presses the button 2904,the application proceeds past the depicted interface regardless of whatinformation has been entered.

FIG. 30 is an illustrative screenshot showing an embodiment of a dealpurchase user interface including a promoter identifier input field. Asdescribed above with reference to FIGS. 11-15, a deal may be presentedon a deal presenter, such as an electronic device located within an FHV.However, screenshot 3000 may be part of any type of promotionscommunication portal or device, such as is described above withreference to FIG. 22. In an embodiment, once a consumer selects a dealfor purchase, the electronic device may display a payment informationuser interface 3000. Interface screen 3000 may include a field forentering payment information 3001, 3002. In certain embodiments theelectronic device includes a field for entering a promoter codeassociated with, for example, the driver of an FHV in which theelectronic device is disposed.

In certain embodiments, it may not be required to enter the promotercode in order to complete the transaction. However, if the code is notentered, the associated promoter may not be compensated as in the casewhere the code is properly entered. In certain embodiments, it isunnecessary for the consumer to enter a promoter code in such anelectronic device, as information associated with the device providesadequate identification of the associated promoter. Various other wayfor inputting promoter identification may be used other than thatdepicted in FIG. 30 or other embodiments disclosed herein, including,for example, scanning a bar code or QR code. As shown, the screen 3000includes a button 3001 for completing the purchase, as well as a button3002 for cancelling the purchase.

FIG. 31 illustrates an embodiment of a promoter contacting system 3100in accordance with one or more embodiments of the present disclosure.The contacting system 3100 includes a deal manager 3110 including atransaction data database 3114 and a promoter contacting module 3114.The transaction data database may include information relating toquantitative and/or qualitative aspects of transactions associated withone or more registered promoters. The promoter contacting module 3116may comprise functionality for communicating via some suitable meanswith one or more registered promoters. For example, the promotercontacting module 3116 may include email addresses, phone numbers,physical addresses, or some other data providing information relating tohow to provide communication to one or more registered promoters. Thepromoter contacting module 3116 may further include a transmitter fortransmitting material over a network to one or more of the promoters3120. The material may include secondary perks or benefits, promotionalmaterials, survey data, among possibly other things.

The system 3100 includes a business or other entity of some kind thatmay have interest in transaction data associated with deal servicepromoters. For example, the business 3140 may be a hotel, casino, orother company or entity. The system 3100 is configured such that thevendor 3140 receives, possibly in response for a request, transactiondata associated with one or more of the promoters 3120 that areregistered with the deal manager 3110. As discussed above, transactiondata may provide information related to the performance of promotersregistered with the deal manager 3110. Such data may be transferred tothe vendor 3140 without disclosing personal identities of promoters, andmay include general information relating to the performance of one ormore of the promoters. Furthermore, the survey questions/data may betransmitted between the deal manager and the vendor 3140 related topromoter input vis-à-vis the vendor or other vendors or topics.

In response to receiving the transaction data, the vendor 3140 may wishto provide benefits, or perks, of some kind and/or promotional materialsto some or all of the promoters 3120. For example, the vendor 3140 maywish to provide benefits or materials to a subset of the promoters 3121,such as a subset of promoters that, by some defined standard, have beenrelatively successful in their promotional activities. In order tofacilitate the conveyance of such materials, the business 3140 mayprovide such to the deal manager 3110. Particularly, the vendor 3140 mayprovide materials or information to the promoter contacting module 3116.Upon receipt of such materials, benefits, or information, the promotercontacting module 3116 may convey the same, or some portion thereof, toone or more of the promoters 3120 in accordance with the desires of thevendor. Therefore, the deal manager 3110 may serve as an intermediarywith respect to communication between a business 3140 and one or morepromoters 3120. In such a system, anonymity of promoters may bemaintained with respect to the vendor 3140. Anonymity may be desirablein order to maintain equality among vendors with respect to ability tocommunicate with promoters. Through anonymity, hiring, compensation of,and evaluation of, promoters may be more likely to be based onmerit/performance. Further, while the vendor does not have access to thenames of the promoters (taxi drivers, for example) the vendor does haveaccess to a group of drivers having the characteristics that the vendorwants to reach (for example, location near vendor, high producerpromoters, promoters who have been successful promoting that vendor).

FIG. 32 is a flow chart depicting an embodiment of a method 3200 ofregistering and compensating a promoter in a deal service system. Themethod may be performed, for example, by one or more processors in adeal manager system. At block 3210, registration information is receivedfrom a promoter, or potential promoter. Such information may bereceived, for example, over a computer network. In response to receivingthe registration information, an identifier associated with thepromoter, such as a unique identifier, may be generated at block 3220.The method 3200 further includes providing the generated identifier insome way to the promoter. In certain embodiments, the identifier istransmitted electronically. However, it may be desirable for thepromoter to physically pick up materials including the identifier at aparticular location. Such a pickup event may serve as an opportunity fora representative of the deal service promoter program to interface withthe promoter, provide materials that are difficult or expensive to ship,educate and/or encourage the promoter.

Following registration of the promoter, the method includes receiving arequest to download a deal service application, such as by a consumer,wherein the request includes communication of the promoter's identifier.For example, the consumer may have input the identifier in response toinformation or prompting received from the promoter. In certainembodiments, the identifier is not included with the download request,but is included at a later point, such as after the application has beenopened or launched on an electronic device of the consumer. Therefore,it should be understood that various aspects of the steps shown in FIG.32 can be performed in connection with steps other than as particularlyillustrated in the figure.

Once the identifier has been received by the deal manager system,compensation is transferred in some manner to the promoter inconsideration for its promotional activity related to the download ofthe application. After downloading the application, the consumer mayproceed to purchase one or more deals, or conduct one or moretransactions using the application, for which it may be desirable tocompensate the promoter. In connection with such a purchase, blocks3270, 3280, and 3290 illustrate steps of receiving a deal acceptance,processing payment information associated with the purchase, andgenerating and sending a voucher associated with the deal to theconsumer.

In certain embodiments, the promoter may be compensated for one or moreadditional transactions carried out by the consumer using theapplication. Therefore, the steps 3260, 3270, 3280, and 3290 provide aloop for processing such future transactions and providing compensationtherefore.

In Operation

In certain embodiments, one or more of the systems and/or methodsdescribed above may operate as follows: A taxi driver may provideregistration information to a deal manager system for the purposes ofbecoming registered as a promoter of deal services with the system. Incertain embodiments, registration of the driver may only be permitted ifthe driver, or his or her employer, has a preexisting businessrelationship with the deal manager system.

In response to receiving the registration information, the driver may beentered in a registered promoters database. Furthermore, the dealmanager system may generate an identifier associated with the driver,and provide the identifier to the driver. In certain embodiments, thedeal manager system provides the identifier together with a collectionof materials, such as in a start-up kit. The kit may include physicaldistribution cards or leaflets on which the driver's identifier isdisplayed. In certain embodiments, the start-up kit is virtual, orelectronic, and may be available on a webpage of the deal managersystem.

The driver may promote deal services provided through the deal managerto passengers of his or her taxi cab. For example, the driver mayverbally encourage passengers to utilize the deal services, or mayprovide promotional materials to them, such as the card displaying thedriver's identifier. A passenger consumer may make a purchase ordownload a deal service application in response to the driver'spromotional efforts. In connection with such purchase or download, theconsumer may have the opportunity to input the driver's identifier,thereby associating the driver with the purchase or download. The drivermay encourage the consumer to input the identifier in order to createsuch an association.

When the deal manager system processes the purchase or download, theassociation between the driver/promoter and the passenger/consumer mayprompt the deal manager to provide notice and/orcompensation/recognition to the driver. This notice/compensation mayencourage the driver in his or her promotional efforts and mayincentivize the driver to engage in further efforts.

The deal manager may maintain data associated with registered promotersproviding information relating to the nature of one or more of theregistered promoters' promotional activities. This data may be useful tovendors or other entities. For example, a vendor may wish to providevouchers or promotional material to promoters based on such data. It maybe desirable for the deal manager to allow the vendor to providematerials to promoters without personally identifying and/or contactingthe promoters. Therefore, the deal manager system may receive thematerials from the vendor and provide them to all, or a subset of, theregistered promoters. For example, a “top performers” subset, or atemporally (for example, within two hours of a show time) orgeographically limited group of the registered promoters may receivecertain materials from a vendor.

The various features and processes described above may be usedindependently of one another, or may be combined in various ways. Allpossible combinations and subcombinations are intended to fall withinthe scope of this disclosure. In addition, certain method or processblocks may be omitted in some implementations. The methods and processesdescribed herein are also not limited to any particular sequence, andthe blocks or states relating thereto can be performed in othersequences that are appropriate. For example, described blocks or statesmay be performed in an order other than that specifically disclosed, ormultiple blocks or states may be combined in a single block or state.The example blocks or states may be performed in serial, in parallel, orin some other manner. Blocks or states may be added to or removed fromthe disclosed example embodiments. The example systems and componentsdescribed herein may be configured differently than described. Forexample, elements may be added to, removed from, or rearranged comparedto the disclosed example embodiments.

Conditional language used herein, such as, among others, “can,” “could,”“might,” “may,” “for example,” and the like, unless specifically statedotherwise, or otherwise understood within the context as used, isgenerally intended to convey that certain embodiments include, whileother embodiments do not include, certain features, elements and/orsteps. Thus, such conditional language is not generally intended toimply that features, elements and/or steps are in any way required forone or more embodiments or that one or more embodiments necessarilyinclude logic for deciding, with or without author input or prompting,whether these features, elements and/or steps are included or are to beperformed in any particular embodiment. The terms “comprising,”“including,” “having,” and the like are synonymous and are usedinclusively, in an open-ended fashion, and do not exclude additionalelements, features, acts, operations, and so forth. Also, the term “or”is used in its inclusive sense (and not in its exclusive sense) so thatwhen used, for example, to connect a list of elements, the term “or”means one, some, or all of the elements in the list. Conjunctivelanguage such as the phrase “at least one of X, Y and Z,” unlessspecifically stated otherwise, is otherwise understood with the contextas used in general to convey that an item, term, etc. may be either X, Yor Z. Thus, such conjunctive language is not generally intended to implythat certain embodiments require at least one of X, at least one of Yand at least one of Z to each be present.

While certain example embodiments have been described, these embodimentshave been presented by way of example only, and are not intended tolimit the scope of the disclosure. Thus, nothing in the foregoingdescription is intended to imply that any particular element, feature,characteristic, step, module, or block is necessary or indispensable.Indeed, the novel methods and systems described herein may be embodiedin a variety of other forms; furthermore, various omissions,substitutions and changes in the form of the methods and systemsdescribed herein may be made without departing from the spirit of theinventions disclosed herein. The accompanying claims and theirequivalents are intended to cover such forms or modifications as wouldfall within the scope and spirit of certain of the inventions disclosedherein.

What is claimed is:
 1. A computer-implemented method of facilitatingcommunication between a vendor and one or more deal promoters, themethod comprising: by a deal manager system comprising one or moreprocessors: storing contact information related to one or more dealpromoters in one or more data storage devices; receiving transactiondata related to promotional activities of the one or more dealpromoters; generating promoter analysis data based at least in part onthe transaction data; providing the promoter analysis data to a vendor;receiving promotional content from the vendor; and providing thepromotional content to the one or more deal promoters using the contactinformation, thereby permitting communication between the vendor and theone or more deal promoters without providing personal identityinformation of the one or more promoters to the vendor.
 2. The method ofclaim 1, wherein the one or more deal promoters are drivers of for-hirevehicles.
 3. The method of claim 1, wherein the contact informationcomprises email addresses.
 4. The method of claim 1, wherein the contactinformation comprises telephone numbers.
 5. The method of claim 1,wherein the one or more deal promoters are a subset of a set of dealpromoters registered with the deal manager system.
 6. The method ofclaim 5, wherein the subset of deal promoters is selected based at leastin part on performance criteria.
 7. The method of claim 6, wherein theperformance criteria is related to promotion of deals associated withthe vendor.
 8. The method of claim 5, wherein the subset of dealpromoters comprises a group of promoters that were involved withpromotion of a relatively high number of deals.
 9. The method of claim5, wherein the subset of deal promoters was selected by the vendor 10.The method of claim 5, further comprising classifying the set ofregistered deal promoters based at least in part on territorialassociation.
 11. The method of claim 5, further comprising classifyingthe set of registered deal promoters based at least in part on workschedule information.
 12. The method of claim 5, further comprisingreceiving selection information selecting
 13. The method of claim 1,wherein the promotional content comprises promotional benefits.
 14. Themethod of claim 13, wherein the promotional content comprises a voucherfor redemption at the venue.
 15. The method of claim 1, wherein thepromotional content comprises advertising material.
 16. The method ofclaim 15, wherein the promotional content comprises material advertisingone or more deals that the deal manager system enables the promoter topromote.
 17. The method of claim 1, further comprising receiving arequest from the vendor for the promoter analysis data.
 18. Acomputer-implemented method of providing benefits to deal promoters, themethod comprising: by a deal manager system comprising one or moreprocessors: receiving registration information from a driver of afor-hire vehicle, wherein the driver is an employee of a first companywith which the deal manager system has a preexisting businessrelationship; storing the registration information in a data storagedevice, the second driver thereby receiving a status as a registeredpromoter with the deal manager system; generating an identifierassociated with the driver; providing the identifier to the driver;processing a consumer transaction associated with the identifier; andproviding a benefit to the driver in response to processing the consumertransaction.
 19. The method of claim 18, further comprising providingsubstantially real-time notification to the driver regarding theconsumer transaction.
 20. The method of claim 18, further comprisingreceiving information from the driver indicating that the driver isemployed by a second company and no longer employed by the firstcompany, wherein: when the second company is a company with which thedeal manager system has a preexisting business relationship, thedriver's registration information is maintained and the driver retainsits status as a registered promoter; and when the second company is nota company with which the deal manager system has a preexisting businessrelationship, the driver's status as a registered promoter isdiscontinued.
 21. The method of claim 20, wherein when the driver'sstatus as a registered promoter is discontinued, the driver'sregistration information is removed from the data storage device. 22.The method of claim 18, wherein the identifier is a unique sequence ofalpha-numeric characters.
 23. The method of claim 22, wherein theidentifier is a number sequence.
 24. The method of claim 22, wherein theconsumer transaction associated with the identifier comprises requestfrom a consumer to download a deal service application, wherein therequest includes the identifier.
 25. The method of claim 22, wherein theconsumer transaction associated with the identifier comprises a dealacceptance received from a consumer, wherein the acceptance includes theidentifier.
 26. The method of claim 22, wherein the benefit is a moneypayment.
 27. A computer-implemented method of providing benefits to dealpromoters, the method comprising by a deal manager system comprising oneor more processors: receiving registration information from a serviceprovider; generating an identifier associated with the service provider;providing the identifier to the service provider; receiving a consumertransaction request including the identifier; and providing compensationto the service provider in response to receiving the request.
 28. Themethod of claim 27, wherein the compensation is calculated based on atransaction type of the consumer transaction request.